Palo Alto Networks Cortex XDR - Investigation and Response
The Palo Alto Networks Cortex XDR - Investigation and Response pack automates Cortex XDR incident response, and includes custom Cortex XDR incident views and layouts to aid analyst investigations.
Cortex XDR is a detection and response app that natively integrates network, endpoint, and cloud data to stop sophisticated attacks.
Responding and managing these attacks requires security teams to reconcile data from multiple sources. Valuable time is lost shuttling between screens and executing repeatable tasks while an attack continues to manifest.
The playbooks included in this pack help you save time and keep your incidents in sync with Cortex XDR. They also help automate repetitive tasks associated with Cortex XDR incidents:
- Syncs and updates Cortex XDR incidents.
- Triggers a sub-playbook to handle each alert by type.
- Extracts and enriches all relevant indicators from the source alert.
- Hunts for related IOCs.
- Calculates the severity of the incident.
- Interacts with the analyst to choose a remediation path or close the incident as a false positive based on the gathered information and incident severity.
- Remediates the incident by blocking malicious indicators and isolating infected endpoints.
The Palo Alto Networks Cortex XDR - Investigation and Response pack enables the following flows:
- Lite Incident Handling - A lite playbook for handling Palo Alto Networks Cortex XDR incidents, which encompasses incident enrichment, investigation, and response for each incident.
- Device Control Violations - Fetch device control violations from XDR and communicate with the user to determine the reason the device was connected.
- XDR Incident Handling - Compare incidents in Palo Alto Networks Cortex XDR and Cortex XSOAR, and update the incidents appropriately.
- Cloud IAM User Access Investigation - Investigates and responds to Cortex XDR Cloud alerts where an Cloud IAM user's access key is used suspiciously to access the cloud environment.
- Cortex XDR - Cloud Cryptomining - Investigates and responds to Cortex XDR XCloud Cryptomining alerts. The playbook Supports AWS, Azure and GCP.
Lite Incident Handling#
This playbook is a lite default playbook to handle XDR incidents, and it doesn't require additional integrations to run. The Palo Alto Networks Cortex XDR - Investigation and Response integration fetches Cortex XDR incidents and runs the Cortex XDR Lite - Incident Handling playbook.
First, the playbook runs the xdr-get-incident-extra-data command to retrieve data fields of the specific incident including a list of alerts with multiple events, alerts, and key artifacts.
Then, the playbook uses the Entity Enrichment Generic v3 sub-playbook which takes all the entities in the incidents and enriches them with the available products in the environment.
In the investigation phase, the playbook uses the Command-Line Analysis sub-playbook to analyze the command line if it exists to determine whether the command line usage was malicious or suspicious.
The playbook also uses the Cortex XDR - Get entity alerts by MITRE tactics sub-playbook to search for alerts related to the endpoint and to the username from Cortex XDR, on a given timeframe, based on MITRE tactics.
Based on the enrichment and the investigation results, the playbook sets the verdict of the incident. Whether the incident verdict is not malicious, the analyst decides whether the incident verdict is malicious or benign.
Whether the verdict is set to malicious by the playbook or by the analyst's decision the playbook will perform remediation actions by isolating the endpoint and blocking all the indicators that were extracted from the incident either manually or automatically using the Block Indicators - Generic v3 sub-playbook. After the remediation stage, the playbook will close the incident.
If the verdict is set to benign, the playbook will close the incident.
As part of this playbook, you'll receive a comprehensive layout that presents incident details, analysis, investigation findings, and the final verdict. Additionally, the layout offers convenient remediation buttons for quicker manual actions.
To utilize this playbook as the default for handling XDR incidents, the classifier should be empty, and the selected incident type should be Cortex XDR - Lite.
The selected Mapper (incoming) should be XDR - Incoming Mapper, and the selected Mapper (outgoing) should be Cortex XDR - Outgoing Mapper.
Device Control Violations#
If a user connects an unauthorized device to the corporate network, such as a USB dongle or a portable hard disk drive, the connection creates an event in Cortex XDR. The Cortex XDR device control violations playbook queries Cortex XDR for device control violations for specified hosts, IP addresses, or XDR endpoint IDs. It then communicates via email with the involved users to understand the nature of the incident and if the user connected the device.
The playbook can enrich data for XDR incidents and determine if there were any device control violations prior to this incident or if there is a correlation between this incident and another one.
You can create a job to periodically query Cortex XDR for device control violations. The dedicated JOB - Cortex XDR query endpoint device control violations playbook enriches the data associated with the endpoint device control events, and creates an incident if any violations are found. The Cortex XDR device control violations playbook is the response playbook for the violations found.
The Cortex XDR device control violations playbook can be used to enrich data for the involved hosts/users in XDR and other incidents.
All collected data is displayed in the XDR device control incident layout.
XDR Incident Handling#
The Palo Alto Networks Cortex XDR - Investigation and Response integration fetches Cortex XDR incidents and runs the Cortex XDR incident handling v3 playbook. This playbook will be triggered by fetching a Palo Alto Networks Cortex XDR incident, but only if the classifier is set to 'Cortex XDR - Classifier' and the incident type is left empty during the integration configuration.
The playbook runs the xdr-get-incident-extra-data command to retrieve data fields of the specific incident including a list of alerts with multiple events, alerts, and key artifacts.
The playbook then searches for similar incidents in Cortex XSOAR to link to the current incident. If a similar incident is found, the analyst will be asked whether to close the current incident as a duplicate since there is an older incident already being handled. The analyst will review the linked incident and decide if the incident should be resolved and closed as a duplicate incident.
If no similar incidents are found, or if the analyst does not want to close the incident as a duplicate, the workflow continues.
The Cortex XDR Alerts Handling sub-playbook loops through and checks the category of the alerts. Currently, this sub-playbook handles Malware, Port Scan and Cloud Cryptomining alerts only. If the category is Malware, the Cortex XDR - Malware Investigation sub-playbook will run. If the category is Port Scan, the Cortex XDR - Port Scan - Adjusted sub-playbook will run and if the category is Cloud Cryptomining, the Cortex XDR - Cloud Cryptomining sub-playbook will run. After the Malware, Port Scan or Cloud Cryptomining sub-playbook runs or if the alert is in any other category, the main playbook will continue to further investigate. It counts the number of alerts in the incident and displays this information in the layout. It then executes the Cortex XDR device control violations sub-playbook.
Then the Entity Enrichment Generic v3 sub-playbook runs which takes all the entities in the incidents and enriches them with the available products in the environment. The SOC team will then do a manual in-depth analysis of the incident.
You can then choose to optionally run the Palo Alto Networks - Hunting And Threat Detection sub-playbook to extract IOCs from the investigation and run them across the organization to check if there are any other compromised accounts or endpoints with the same information that was detected in this alert.
The severity of the incident is calculated by the Calculate Severity - Generic v2 sub-playbook.
Based on the severity, the analyst decides whether to continue to the remediation stage or close the investigation as a false positive. The remediation blocks all the indicators that were extracted from the incident either manually or automatically using the Block Indicators - Generic v2 sub-playbook.
If this was a port scan alert, the analyst will manually block the ports used for the exploitation on the scanned hosts.
After the remediation, if there are no new alerts, the playbook stops the alert sync and closes the XDR incident and investigation.
To utilize this playbook for handling XDR incidents, the classifier that should be selected is Cortex XDR - Classifier.
The selected Mapper (incoming) should be XDR - Incoming Mapper, and the selected Mapper (outgoing) should be Cortex XDR - Outgoing Mapper.
Syn Indicators between Cortex XSOAR and Cortex XDR#
The Cortex XDR - IOCs feed integration syncs indicators between Cortex XSOAR and Cortex XDR. The integration syncs indicators according to the defined fetch interval. At each interval, the integration pushes new and modified indicators defined in the Sync Query from Cortex XSOAR to Cortex XDR. Additionally, the integration checks if there are manual modifications of indicators on Cortex XDR and syncs back to Cortex XSOAR. Once per day, the integration performs a complete sync which also removes indicators that have been deleted or expired in Cortex XSOAR, from Cortex XDR.
Cloud IAM User Access Investigation#
The Cloud IAM user access investigation playbook investigates and responds to Cortex XDR Cloud alerts where an Cloud IAM user's access key is used suspiciously to access the cloud environment.
The playbook fetches data from the incident and then retrieves additional cloud alert data that was not available in the incident. It then checks if the alerts are one of the following XCLOUD supported alerts:
- Penetration testing tool attempt
- Penetration testing tool activity
- Suspicious API call from a Tor exit node
If the alert is not one of the supported alerts, the playbook ends. Otherwise, the incident type is set to XCLOUD and the playbook starts to collect additional information pertaining to the alert.
First the source IP addresses are enriched. These are the IP addresses that are used to connect to the environment.
Then the playbook enriches information about the user who connected to the environment through the relevant IAM integration using the Cloud IAM Enrichment - Generic sub-playbook. The sub-playbook lists the user access keys and retrieves information about the IAM user, including the user's creation date, path, unique ID, and ARN. From this, it can be seen if these user keys are active and the analyst can block these keys later in the investigation if they are causing malicious activities.
Based on the enrichment and the analysis results, the playbooks sets the verdict of the incident. If malicious indicators are found, the playbook takes action using Cloud Response - Generic sub-playbook. If the verdict not determined, it lets the analyst decide whether to continue to the remediation stage or close the investigation.
The analyst looks at any persistence, for example, a new user or key creation or for any lateral movement operations. For example, an operation can be = AsumeRole. As an extra validation step, it is recommended to query the user and/or the user’s manager regarding the investigated suspicious activity.
Based on this investigation, the analyst manually decides if the alert is a false or true positive. If false, the playbook ends.
Cortex XDR - Cloud Cryptomining#
The Cortex XDR - Cloud Cryptomining playbook enriches, investigates, and responds to Cortex XDR XCloud Cryptomining alerts. The playbook flow is triggered based on the 'Unusual allocation of multiple cloud compute resources' alert. If the alert isn't present in the incident, the playbook will exit the IR flow.
First, the playbook will fetch and map the raw JSON of the alert to context.
Then the playbook enters the Cortex XDR - Cloud Enrichment playbook and collects and enriches the following:
- Resource enrichment
- Previous activity is seen in the specified region or project
- Account enrichment
- Network enrichment
- Attacker IP
- Geolocation
- ASN
Also, the playbook will collect data for later usage in the layout.
After collecting and enriching the data, the playbook enters the Cortex XDR - Cryptomining - Set Verdict playbook. This playbook will set the incident verdict as Unknown or Malicious based on the following decision tree logic:
- If the source IP address is malicious.
- If the incident includes both "Unusual allocation of multiple cloud compute resources" AND "Cloud identity reached a throttling API rate" (medium/high severity).
- If the incident includes both "Unusual allocation of multiple cloud compute resources" AND "Suspicious heavy allocation of compute resources - possible mining activity".
- If the incident includes "Unusual allocation of multiple cloud compute resources" with medium/high severity, the source ASN isn't known, and the source IP isn't known.
- If the incident includes both "Unusual allocation of multiple cloud compute resources" AND "A cloud compute instance was created in a dormant region".
- If none of the conditions is true, the playbook will wait for an analyst's decision.
If the analyst approves the activity, the False Positive flow will be executed, and the incident severity will be set as 'low'.
If the activity is not approved by the analyst or the Cortex XDR - Cryptomining - Set Verdict playbook final verdict is malicious, the response flow is executed. These are the primary response steps:
- Setting the incident severity as 'high'.
- Sending a message to the SOC.
- Executing the Cloud Response - Generic playbook.
The Cloud Response - Generic playbook provides response playbooks for:
- AWS
- Azure
- GCP
The response actions available are:
- Terminate/Shut down/Power off an instance.
- Delete/Disable a user.
- Delete/Revoke/Disable credentials.
- Block indicators.
The playbook will move forward for the analyst's resolution when the response phase has finished.
In This Pack#
The Palo Alto Networks Cortex XDR - Investigation and Response content pack includes several content items.
Automations#
- EntryWidgetNumberHostsXDR: Entry widget that returns the number of hosts in a Cortex XDR incident.
- EntryWidgetNumberUsersXDR: Entry widget that returns the number of users that participated in a specified Cortex XDR incident.
- EntryWidgetPieAlertsXDR: Entry widget that returns a pie chart of alerts for a specified Cortex XDR incident by alert severity (low, medium, and high).
- XDRSyncScript: Deprecated. The incoming and outgoing mirroring feature added in XSOAR version 6.0.0 is used instead to sync XDR. After the Calculate Severity - Generic v2 sub-playbook’s run, Cortex XSOAR will be treated as the single source of truth for the severity field, and it will sync only from Cortex XSOAR to XDR, so manual changes for the severity field in XDR will not update in the XSOAR incident.
Classifiers#
- Cortex XDR - Classifier: Classifies Cortex XDR incidents.
- Cortex XDR - Incoming Mapper: Maps incoming Cortex XDR incidents fields.
- Cortex XDR - Outgoing Mapper: Maps outgoing Cortex XDR incidents fields.
Incident Types#
- Cortex XDR Device Control Violations
- Cortex XDR Disconnected endpoints
- Cortex XDR Incident
- Cortex XDR Port Scan
- Cortex XDR - XCLOUD
Incident Fields#
- LastMirroredInTime
- XDR Alert Count
- XDR Alerts
- XDR Assigned User Email
- XDR Assigned User Pretty Name
- XDR Description
- XDR Detection Time
- XDR device control violations
- XDR Disconnected endpoints
- XDR File Artifacts
- XDR High Severity Alert Count
- XDR Host Count
- XDR Incident ID
- XDR Low Severity Alert Count
- XDR manual severity
- XDR Medium Severity Alert Count
- XDR Modification Time
- XDR Network Artifacts
- XDR Notes
- XDR Resolve Comment
- XDR Status (Deprecated from version 6.0.0. Use XDR Status v2 instead)
- XDR Status v2
- XDR URL
- XDR User Count
Indicator Fields#
XDR status: The indicator status in XDR.
Integrations#
Cortex XDR - IOC#
Syncs indicators between Cortex XSOAR and Cortex XDR.
Palo Alto Networks Cortex XDR - Investigation and Response#
Enables direct execution of Cortex XDR actions within Cortex XSOAR.
Layouts#
There are 5 layouts in this pack. The information displayed in the layouts are similar with minor changes as detailed below.
Cortex XDR Device Control Violations layout#
| Layout sections | Description |
|---|---|
| Case Details | Displays the following information associated with the incident: Type, Severity, and Playbook. |
| XDR Device Control Violations | A table displaying the following information about the incident: host name, user name, IP address, violation type, and the date the violation occurred. |
| Affected Hosts Count | Color-coded field that displays the number of hosts affected by the incident. The color indication is as follows: green - 0 hosts, orange - 1-3 hosts, red - 4 or more hosts. |
| Affected Users Count | Color-coded field that displays the number of users affected by the incident. The color indication is as follows: green - 0 users, orange - 1-3 users, red - 4 or more users. |
| Notes | Comments entered by the user regarding the incident. |
| Linked Incidents | Displays any incident that is linked to the current incident. |
Cortex XDR Disconnected endpoints#
| Layout sections | Description |
|---|---|
| Case Details | Displays the following information associated with the incident: Type, Source Instance, Severity, Owner, Playbook, and Source Brand. |
| Affected Users Count | Color-coded field that displays the number of users affected by the incident. The color indication is as follows: green - 0 users, orange - 1-3 users, red - 4 or more users. |
| Affected Hosts Count | Color-coded field that displays the number of hosts affected by the incident. The color indication is as follows: green - 0 hosts, orange - 1-3 hosts, red - 4 or more hosts. |
| Notes | Comments entered by the user regarding the incident. |
| XDR Disconnected endpoints | Displays a table with the following information for the disconnected endpoints: Endpoint Name, Endpoint Status, Endpoint OS, Endpoint ID, and Endpoint Last Seen. |
| Disconnected endpoints report | Displays a report for the disconnected endpoints. |
| Linked Incidents | Displays any incident that are linked to this incident. |
Cortex XDR Incident#
This layout has two tabs:
Case Info Tab#
| Layout sections | Description |
|---|---|
| Case Details | Displays the following information associated with the incident: Type, Source Instance, Source Brand, Severity, Owner, and Playbook. |
| XDR Basic Information | Displays XDR basic information that includes: XDR description, XDR Incident ID, XDR Status v2, XDR Host Count, XDR User Count, XDR Notes, XDR URL, XDR Alert Count. |
| Related Alerts Severity | Displays the alerts severity in the XDR incident. |
| Affected Hosts Count | Color-coded field that displays the number of hosts affected by the incident. The color indication is as follows: green - 0 hosts, orange - 1-3 hosts, red - 4 or more hosts. |
| Affected Users Count | Color-coded field that displays the number of users affected by the incident. The color indication is as follows: green - 0 users, orange - 1-3 users, red - 4 or more users. |
| Timeline Information | Displays general information about the handling of the incident. |
| Team Members | Displays a list of the analysts who worked on this incident. |
| Notes | Comments entered by the user regarding the incident. |
| Evidence | Displays the data that analysts marked as evidence for this incident. |
| Linked Incidents | Displays the incidents that were linked to the current incident. |
| Closing Information | Displays the information that the analyst reported about closing the incident. |
| Mirroring Information | Displays general mirroring information for this incident. |
Investigation Tab#
| Layout sections | Description |
|---|---|
| XDR Alerts | Displays the following XDR alert information: Alert ID, Detection Timestamp, Severity, Name, Category, Action, Action Pretty, Description, Host IP, Host Name, User Name, MITRE ATTACK TACTIC, and MITRE ATTACK TECHNIQUE, |
| XDR File Artifacts | Displays the following information about the XDR file artifacts: File Name, File SHA256, Alert Count, File Wildfire Verdict, File Signature Vendor Name, and File Signature Status. |
| XDR Network Artifacts | Displays the following information about the XDR network artifacts: Type, Alert Count, Is Manual, Network Domain, Network Remote IP, Network Remote Port, and Network Country. |
| XDR Endpoint Device Control Violations | Displays the following information about the XDR endpoint device control violations: Hostname, Username, IP, XdR endpoint ID, Violation type, and Date. |
| Indicators | Displays the following information about the indicators: Type, Value, Reputation, First Seen, and Last Seen. |
| Incident Files | Displays the Incident Files that can be seen in the War Room. |
Cortex XDR Port Scan#
| Layout sections | Description |
|---|---|
| Case Details | Displays the following information associated with the incident: Type, Source Instance, Source Brand, Owner, and Playbook. |
| XDR Basic Information | Displays XDR basic information that includes: XDR Description, XDR Incident ID, XDR Status, XDR Host Count, XDR User Count, XDR Notes, XDR URL, XDR Alert Count, XDR High Severity, XDR Medium Severity, XDR Assigned User Email, Source IP, and Source Hostname. |
| Related Alerts Severity | Displays the alerts severity in the XDR incident. |
| Affected Hosts Count | Color-coded field that displays the number of hosts affected by the incident. The color indication is as follows: green - 0 hosts, orange - 1-3 hosts, red - 4 or more hosts. |
| Affected Users Count | Color-coded field that displays the number of users affected by the incident. The color indication is as follows: green - 0 users, orange - 1-3 users, red - 4 or more users. |
| Timeline Information | Displays general information about the handling of the incident. |
| Team Members | Displays a list of the analysts who worked on this incident. |
| Notes | Comments entered by the user regarding the incident. |
| Evidence | Displays the data that analysts marked as evidence for this incident. |
| Linked Incidents | Displays the incidents that were linked to the current incident. |
| Closing Information | Displays the information that the analyst reported about closing the incident. |
Cortex XDR - XCLOUD layout#
This layout has two tabs:
Incident Info Tab#
| Layout sections | Description |
|---|---|
| Incident Information | Displays XDR basic information that includes: XDR Description, XDR Incident ID, XDR URL, XDR Alert Category, XDR Alert Name, Created, XDR Host Count, XDR User Count, XDR Alert Count, XDR High Severity Alert Count, XDR Medium Severity Alert Count, and XDR Low Severity Count. |
| Case Details | Displays the following information associated with the incident: Type, Severity, Source Brand, Source Instance, and Playbook. |
| Alert Severity | Displays the alert severity in the XDR incident. |
| Cloud Provider | Displays the host's cloud provider. |
| Users Count | Color-coded field that displays the number of users affected by the incident. The color indication is as follows: green - 0 users, orange - 1-3 users, red - 4 or more users. |
| Work Plan | Information regarding the playbook tasks from the Work Plan. You can view details by clicking the Tasks Pane or Work Plan links. |
| Team Members | Displays a list of the analysts who worked on this incident. |
| Linked Incidents | Displays any incident that is linked to the current incident. |
| Notes | Comments entered by the user regarding the incident. |
| Mirroring Information | Displays general mirroring information for this incident, including Mirror Instance, Mirror Direction, Mirror External ID, Mirror Last Sync, Mirror Tags, and Incoming Mirror Error. |
| Closing Information | Displays the information that the analyst reported about closing the incident. |
Alert Info Tab#
| Layout sections | Description |
|---|---|
| XDR Alerts | Displays alert information including: Alert ID, Detection Timestamp, Severity, Name, Category, Action, Action Pretty, Description, Host IP, Host Name, User Name, MITRE ATTACK TACTIC, and MITRE ATTACK TECHNIQUE. |
| Original Alert Additional Information | Displays the following information: Alert Full Description, Detection Module, Vendor, Provider, Log Name, Event Type, Caller IP, Caller IP Geo Location, Resource Type, Identity Name, Operation Name, Operation Status, and User Agent. |
| Identity Information | Displays the following information: Name, Type, Sub Type, Uuid, Provider, and Access Keys. |
| Remediation Actions Information | Displays the Inactive Access keys, and the Deleted Login Profiles. |
| Indicators | Displays the following information: Type, Value, Verdict, First Seen, Last Seen, Source Time Stamp Related Incidents, Source Brands, Source Instances, Expiration Status, and Expiration. |
Playbooks#
There are several playbooks in this pack.
Cortex XDR - Check Action Status#
Checks the action status of an action ID. Enter the action ID of the action whose status you want to know.
Cortex XDR - Isolate Endpoint#
Accepts an XDR endpoint ID and isolates it using the Palo Alto Networks Cortex XDR - Investigation and Response integration.
Cortex XDR - Unisolate Endpoint#
Accepts an XDR endpoint ID and unisolates it using the Palo Alto Networks Cortex XDR - Investigation and Response integration.
Cortex XDR - Malware Investigation#
Investigates a Cortex XDR incident containing malware alerts. The playbook:
- Enriches the infected endpoint details.
- Lets the analyst manually retrieve the malicious file.
- Performs file detonation.
The playbook is used as a sub-playbook in the following playbooks:
Cortex XDR - Port Scan#
Investigates a Cortex XDR incident containing internal port scan alerts. The playbook:
- Syncs data with Cortex XDR.
- Enriches the hostname and IP address of the attacking endpoint.
- Notifies management about host compromise.
- Escalates the incident in case of lateral movement alert detection.
- Hunts malware associated with the alerts across the organization.
- Blocks detected malware associated with the incident.
- Blocks IPs associated with the malware.
- Isolates the attacking endpoint.
- Allows manual blocking of ports that were used for host login following the port scan.
The playbook is used as a sub-playbook in the following playbooks:
Cortex XDR - Port Scan - Adjusted#
Investigates a Cortex XDR incident containing internal port scan alerts. The playbook:
- Syncs data with Cortex XDR.
- Notifies management about a compromised host.
- Escalates the incident in case of lateral movement alert detection.
Cortex XDR - quarantine file#
Accepts file paths, file hashes, and endpoint IDs in order to quarantine a selected file.
Cortex XDR - Retrieve File Playbook#
Retrieves files from selected endpoints. You can retrieve up to 20 files, from no more than 10 endpoints. Inputs for this playbook are:
- A comma-separated list of endpoint IDs.
- A comma-separated list of file paths for your operating system, either Windows, Linux, or Mac. At least one file path is required.
Cortex XDR Alerts Handling#
Loops over every alert in a Cortex XDR incident. It is used as a sub-playbook in the Cortex XDR incident handling v3 playbook. Currently, the supported alert categories are:
- Malware
- Port Scan
Cortex XDR device control violations#
Queries Cortex XDR for device control violations for the specified hosts, IP address, or XDR endpoint ID. It then communicates via email with the involved users to understand the nature of the incident and if the user connected the device. All the collected data is displayed in the XDR device control incident layout. This playbook is also used as the response playbook for the JOB - Cortex XDR query endpoint device control violations playbook or as a sub-playbook in the Cortex XDR Incident Handling - v3.
JOB - Cortex XDR query endpoint device control violations#
A job to periodically fetch endpoint device control events and enrich the data associated with the endpoint device control events. It creates an incident if any violations are found. The Cortex XDR device control violations playbook is the response playbook for the violations found.
Cortex XDR disconnected endpoints#
A job to periodically query disconnected Cortex XDR endpoints with a provided last seen time range playbook input. The collected data generates a CSV report, including a detailed list of the disconnected endpoints. The report will be sent to email addresses provided in the playbook input. The playbook includes an incident type with a dedicated layout to visualize the collected data.
Cortex XDR Lite - Incident Handling#
This playbook is a lite default playbook to handle XDR incidents, and it doesn't require additional integrations to run. The playbook is triggered by fetching a Palo Alto Networks Cortex XDR incident. First, The playbook performs enrichment on the incident’s indicators. Then, the playbook performs investigation and analysis on the command line and search for related Cortex XDR alerts by Mitre tactics to identify malicious activity performed on the endpoint and by the user. Based on the enrichment and the investigation results, the playbooks sets the verdict of the incident. If malicious indicators are found, the playbook takes action to block these indicators and isolate the affected endpoint to prevent further damage or the spread of threats. If the verdict not determined, it lets the analyst decide whether to continue to the remediation stage or close the investigation as benign. As part of this playbook, you'll receive a comprehensive layout that presents incident details, analysis, investigation findings, and the final verdict. Additionally, the layout offers convenient remediation buttons for quicker manual actions.
Cortex XDR Incident Handling#
This playbook is triggered by fetching a Palo Alto Networks Cortex XDR incident. Syncs and updates new XDR alerts that construct the incident. It enriches indicators using Threat Intelligence integrations and Palo Alto Networks AutoFocus. The incident's severity is then updated based on the indicators' reputation and an analyst is assigned for manual investigation. If chosen, automated remediation with Palo Alto Networks FireWall is initiated. After a manual review by the SOC analyst, the XDR incident is closed automatically.
Note - The XDRSyncScript used by this playbook sets data in the XDR incident fields that were released to content from the Cortex XSOAR server version 5.0.0. For Cortex XSOAR versions under 5.0.0, follow the Palo Alto Networks Cortex XDR documentation to upload the new fields manually.
Cortex XDR incident handling v2#
This playbook is triggered by fetching a Palo Alto Networks Cortex XDR incident. The playbook syncs and updates new XDR alerts that construct the incident and triggers a sub-playbook to handle each alert by type. Then, the playbook performs enrichment on the incident's indicators and hunting for related IOCs. Based on the severity, it lets the analyst decide whether to continue to the remediation stage or close the investigation as a false positive. After the remediation, if there are no new alerts, the playbook stops the alert sync and closes the XDR incident and investigation.
Cortex XDR incident handling v3#
This playbook is triggered by fetching a Palo Alto Networks Cortex XDR incident, but only if the classifier is set to 'Cortex XDR - Classifier' and the incident type is left empty during the integration configuration. The playbook syncs and updates new XDR alerts that construct the incident and triggers a sub-playbook to handle each alert by type. Then, the playbook performs enrichment on the incident’s indicators and hunts for related IOCs. Based on the severity, it lets the analyst decide whether to continue to the remediation stage or close the investigation as a false positive. After the remediation, if there are no new alerts, the playbook stops the alert sync and closes the XDR incident and investigation. For performing the bidirectional sync, the playbook uses the incoming and outgoing mirroring feature added in XSOAR version 6.0.0. After the Calculate Severity - Generic v2 sub-playbook’s run, Cortex XSOAR will be treated as the single source of truth for the severity field, and it will sync only from Cortex XSOAR to XDR, so manual changes for the severity field in XDR will not update in the XSOAR incident.
Cortex XDR Incident Sync#
Compares incidents in Palo Alto Networks Cortex XDR and Cortex XSOAR, and updates the incidents appropriately. When an incident is updated in Cortex XSOAR, the XDRSyncScript will update the incident in XDR. When an incident is updated in XDR, the XDRSyncScript will update the incident fields in Cortex XSOAR and rerun the current playbook. Do not use this playbook when enabling the incident mirroring feature added in XSOAR version 6.0.0.
Cortex XDR - Block File#
Adds files to the Cortex XDR block list with a given file SHA256 playbook input.
Cortex XDR - Delete file#
Deletes the specified file and retrieves the results.
Cortex XDR - Execute snippet code script#
Initiates a new endpoint script execution action using the provided snippet code and retrieve the file results.
Cortex XDR - Run script#
Initiates a new endpoint script execution action using a provided script unique ID from the Cortex XDR script library.
Cortex XDR - check file existence#
Checks if the specified file exists.
Cortex XDR - execute commands#
Executes specified shell commands.
Cortex XDR - kill process#
Kills the specified process.
Cortex XDR - Cloud IAM user access investigation#
Investigates and responds to Cortex XDR Cloud alerts where an Cloud IAM user`s access key is used suspiciously to access the cloud environment.
The following alerts are supported for all cloud environments:
- Penetration testing tool attempt
- Penetration testing tool activity
- Suspicious API call from a Tor exit node
Before You Start#
Required Content Packs#
This Content Pack may require the following additional Content Packs:
- Active Directory Query
- Base
- Common Playbooks
- Common Scripts
Optional Content Packs#
- AutoFocus
- Core REST API
- EWS
- EWS Mail Sender
- Gmail
- Gmail Single User (Beta)
- Mail Sender (New)
- Microsoft Graph Mail Single User
- Microsoft Graph Mail
- PANW Comprehensive Investigation
- Port Scan
Pack Configurations#
Device Control Violations Workflow#
Create a job to query for device control violations.
Click Jobs.
Click New Job.
Configure the recurring schedule.
Enter a name for the job.
In the Type field, select XDR Device Control Violations.
In the Playbook field, select JOB - Cortex XDR query endpoint device control violations.
Click Create new job.
Note: For detailed information about creating jobs, see Jobs.
Define the inputs for the JOB - Cortex XDR query endpoint device control violations.
Note: The scheduled run time and the timestamp playbook input must be identical. If the job recurs every 7 days, the timestamp should be 7 days as well.
To run the response playbook for the violations found, define the inputs for the Cortex XDR device control violations.
Query Disconnected Cortex XDR Endpoints Workflow#
Create a job to query the disconnected endpoints.
Click Jobs.
Click New Job.
Configure the recurring schedule.
Enter a name for the job.
In the Type field, select Cortex XDR disconnected endpoints.
In the Playbook field, select Cortex XDR disconnected endpoints.
Click Create new job.
Note: For detailed information about creating jobs, see Jobs.
Define the inputs for the Cortex XDR disconnected endpoints playbook.
Note: The scheduled run time and the timestamp playbook input must be identical. If the job recurs every 7 days, the timestamp should be 7 days as well.