Core

Searches for a specific indicator in the tenant's event and log data, and extracts the logs the indicator appears in.

Computes the distance between two sets of coordinates, in miles.

The Cortex Core IR integration uses the Cortex API for detection and response, by natively integrating network, endpoint, and cloud data to stop sophisticated attacks.

XQL Query Engine enables you to run XQL queries on your data sources.

The Cortex Core - IOCs integration uses the Cortex API for detection and response, by natively integrating network, endpoint, and cloud data to stop sophisticated attacks.

Default layout

IOCs provide the ability to alert on known malicious objects on endpoints across the organization.

Analysis Actions:
The playbook will use several enrichment sources to determine the IOC verdict. Additionally, will use the Analytics module to run a prevalence check for the IOC.

Response Actions:
The playbook's first response action is a containment plan that is based on the playbook input. In that phase, the playbook will execute endpoint isolation

Investigative Actions:
When the playbook executes, it checks for additional abnormal activity using the Endpoint Investigation Plan playbook that can indicate the endpoint might be compromised.

Remediation Actions:
In case results are found within the investigation phase, the playbook will execute remediation actions that include containment and eradication.

This phase will execute the following containment actions:

• File quarantine
• Endpoint isolation

And the following eradication actions:

• Manual process termination
• Manual file deletion.

Deprecated. Use Cloud IAM User Access Investigation instead. Respond to Cortex XDR Cloud alerts where an AWS IAM user`s access key is used suspiciously to access the cloud environment.
The following alerts are supported for AWS environments.

• Penetration testing tool attempt
• Penetration testing tool activity
• Suspicious API call from a Tor exit node
  This is a beta playbook, which lets you implement and test pre-release software. Although AWS is supported, we are working towards multi-cloud support. As the playbook is beta, it might contain bugs. Updates to the playbook during the beta phase might include non-backward compatible features. We encourage your feedback on the quality and usability of the content to help us identify and fix issues, so we can continually improve the content.

This playbook investigates a scan where the source is an internal IP address.

An attacker might initiate an internal scan for discovery, lateral movement and more.

Attacker's Goals:

An attacker can leverage a scan for open ports and vulnerable systems on remote endpoints in an attempt to identify the endpoint operating system, firewall configuration, and exploitable services.

Investigative Actions:

• Endpoint Investigation Plan playbook

Response Actions

The playbook's response actions are based on the Endpoint Investigation Plan playbook results. In that phase, the playbook will execute:

• Auto endpoint isolation
• Manual block indicators
• Manual file quarantine

The playbook investigates Cortex XDR alerts involving large upload alerts.
The playbook consists of the following procedures:

• Searches for similar previous alerts that were closed as false positives.
• Enrichment and investigation of the initiator and destination hostname and IP address.
• Enrichment and investigation of the initiator user, process, file, or command if it exists.
• Detection of related indicators and analysis of the relationship between the detected indicators.
• Utilize the detected indicators to conduct threat hunting.
• Blocks detected malicious indicators.
• Endpoint isolation.
  This playbook supports the following Cortex XDR alert names:
• Large Upload (Generic)
• Large Upload (SMTP)
• Large Upload (FTP)
• Large Upload (HTTPS)

When an unknown executable, DLL, or macro attempts to run on a Windows or Mac endpoint, the Cortex XDR agent uses local analysis to determine if it is likely to be malware. Local analysis uses a static set of pattern-matching rules that inspect multiple file features and attributes, and a statistical model that was developed with machine learning on WildFire threat intelligence.

Investigative Actions:

Investigate the executed process image and verify if it is malicious using:

• XDR trusted signers
• VT trusted signers
• VT detection rate
• NSRL DB

Response Actions

The playbook's first response action is a containment plan that is based on the initial data provided within the alert. In that phase, the playbook will execute:

• Auto block indicators
• Auto file quarantine
• Manual endpoint isolation

When the playbook executes, it checks for additional activity using the Endpoint Investigation Plan playbook, and another phase, which includes containment and eradication, is executed.

This phase will execute the following containment actions:

• Manual block indicators
• Manual file quarantine
• Auto endpoint isolation

And the following eradication actions:

• Manual process termination
• Manual file deletion
• Manual reset of the user’s password

External resources:

Malware Protection Flow

This playbook detects the ransomware type and searches for available decryptors.

The playbook uses the ID-Ransomware service, which allows you to detect the ransomware using multiple methods.

The "Remote PsExec-like LOLBIN Command Execution" playbook is designed to address and respond to alerts indicating suspicious activities related to remote PsExec-like LOLBIN command execution from an unsigned non-standard source.
The playbook aims to efficiently:

• Check if the execution is blocked. If not will terminate the process (Manually by default).
• Enrich any entities and indicators from the alert and find any related campaigns.
• Perform command analysis to provide insights and verdict for the executed command.
• Perform further endpoint investigation using XDR.
• Checks for any malicious verdict found to raise the severity of the alert.
• Perform Automatic/Manual remediation response by blocking any malicious indicators found.

The playbook is designed to run as a sub-playbook in ‘Cortex XDR Alert Handling - v3 & Cortex XDR Alerts Handling’.
It depends on the data from the parent playbooks and can not be used as a standalone version.

This playbook handles ransomware alerts based on the Cortex XDR Traps module signature 'Suspicious File Modification'

Attacker’s Goals:

An attacker is attempting to encrypt the victim files for either extortion or destruction purposes.

Investigative Actions:

Investigate the executed process image and verify if it is malicious using:

XDR trusted signers

VT trusted signers

VT detection rate

NSRL DB

Response Actions:

The playbook’s first response action is a remediation plan which includes two sub-playbooks, Containment Plan and Eradication Plan, which is based on the initial data provided within the alert. In that phase, the playbooks will execute:

Auto endpoint isolation

Auto block indicators

Auto file quarantine

Auto user disable

Auto process termination

Next, the playbook executes an enrichment and response phase which includes two sub-playbooks, Ransomware Enrich and Contain & Account Enrichment - Generic v2.1.
The Ransomware Enrich and Contain playbook does the following:

1.Checks if the initiator is a remote attacker and allows isolating the remote host, if possible.

2.Retrieves the WildFire sandbox report and extracts the indicators within it. * The playbook tries to retrieve the report, but if there is no report available, the playbook tries to fetch the ransomware file for detonation.

3.Hunts for the ransomware alert indicators from the alert table, searches for endpoints that have been seen with them, and allows containing the identified endpoints.

Next, an advanced analysis playbook, which is currently done mostly manually, will be executed. This sub-playbook, Ransomware Advanced Analysis allows the analyst to upload the ransomware note and for the ransomware identification. Using the ID-Ransomware service, the analyst will be able to get the ransomware type and the decryptor if available.

When the playbook executes, it checks for additional activity using the Endpoint Investigation Plan playbook, and another phase, which includes the Containment Plan sub-playbook, is executed.

This phase will execute the following containment actions:

Manual block indicators

Manual file quarantine

Auto endpoint isolation

Finally, the recovery phase is executed. If the analysts decides to continue with the investigation rather than recover and close the alert, a manual task with CISA official ransomware investigation checklist is provided for further investigation.

External resources:

MITRE Technique T1486

CISA Ransomware Guide

This playbook handles command and scripting interpreter alerts based on the MITRE T1059 technique.
An attacker might abuse command and script interpreters to execute commands, scripts, or binaries.
Most systems come with some kind of built-in command line interface and scripting capabilities. For example, macOS and Linux distributions include some form of Unix Shell while Windows installations include the Windows Command Shell and PowerShell.

Attacker's Goals:

An attacker can abuse these technologies in various ways as a means of executing arbitrary commands. Commands and scripts can be embedded in initial access payloads delivered to victims as lure documents or as secondary payloads downloaded from an existing C2. An attacker may also execute commands through interactive terminals/shells, as well as utilize various remote services to achieve remote execution.

Analysis

Due to the nature of this technique and the usage of built-in command line interfaces, the first step of the playbook is to analyze the command line.
The command line analysis does the following:

• Checks and decodes base64
• Extracts and enriches indicators from the command line
• Checks specific arguments for malicious usage

Investigative Actions:
The playbook checks for additional activity using the 'Endpoint Investigation Plan' playbook and utilizes the power of insight alerts.

Response Actions

After analyzing the data, the playbook's first response action is to contain the threat based on the initial data provided within the alert. In this phase, the playbook will:

• Isolate the endpoint based on playbook inputs.

When the playbook proceeds, it checks for additional activity using the 'Endpoint Investigation Plan' playbook. It then continues with the next stage, which includes, containment and eradication.

This phase executes the following containment actions:

• Automatically isolates the endpoint

It then continues with the following eradication actions:

• process termination

This playbook handles masquerading alerts based on the MITRE T1036 technique.
An attacker might leverage Microsoft Windows well-known image names to run malicious processes without being caught.

Attacker's Goals:

An attacker is attempting to masquerade as standard windows images by using a trusted name to execute malicious code.

Investigative Actions:

Investigate the executed process image and verify if it is malicious using:

• XDR trusted signers
• VT trusted signers
• VT detection rate
• NSRL DB

Response Actions

The playbook's first response action is a containment plan which is based on the initial data provided within the alert. In that phase, the playbook will execute:

• Auto block indicators
• Auto file quarantine
• Manual endpoint isolation

When the playbook executes, it checks for additional activity using the Endpoint Investigation Plan playbook, and another phase, which includes containment and eradication, is executed.

This phase will execute the following containment actions:

• Manual block indicators
• Manual file quarantine
• Auto endpoint isolation

And the following eradication actions:

• Manual process termination
• Manual file deletion
• Manual reset of the user’s password

External resources:

MITRE Technique T1036

Possible Microsoft process masquerading

This playbook creating an array called "Suspicious Elements", which is used to count potential security threats. The following elements can be added to the array:

• "IP Reputation" - DBot Score is 2-3
• "Source geolocation" - RDP Connection made from rare geo-location
• Related to campaign - IP address is related to campaign, based on TIM module
• Hunting results - the hunt for indicators related to the source IP and the related campaign returned results
• XDR Alert search - XDR Alerts that related to the same username and endpoint, and to the MITRE tactics that comes after "Credential Access", were found.
• Risky User - one or more risky users are involved in the alert, as identified by the Cortex Core - IR integration's ITDR module.
• Risky Host - one or more risky hosts are involved in the alert, as identified by the Cortex Core - IR integration's ITDR module.

The array will then be outputted and its size will be compared to a final threshold. If the size is greater than or equal to the threshold, the investigation's final verdict will be deemed a "True Positive."

This playbook investigates a “Possible External RDP Brute Force” XDR Alert by gathering user, IP, and hostname information, and investigating if the following suspicious elements exists:

• "IP Reputation" - DBot Score is 2-3
• "Source geolocation" - RDP Connection made from rare geo-location
• Related to campaign - IP address is related to campaign, based on TIM module
• Hunting results - the hunt for indicators related to the source IP and the related campaign returned results
• XDR Alert search - XDR Alerts that related to the same username and endpoint, and to the MITRE tactics that comes after "Credential Access", were found.
• Risky User - The user that was identified in the attack was given a medium or high score by the Core integration's ITDR module.
• Risky Host - The destination host that was identified in the attack was given a medium or high score by the Core integration's ITDR module.

Set verdict method:

• Critical Element - The "Critical Element" input allows you to select a specific element that, if identified as suspicious, the investigation's final verdict will be deemed a "True Positive".

• Final Verdict - Each suspicious element is being added to an array called "Suspicious Elements", which is used to count potential security threats. The array size will be compared to a final threshold. If the size is greater than or equal to the threshold, the investigation's final verdict will be deemed a "True Positive".

• User Engagement - The "UserEngagementThreshold" input allows you to set the number of suspicious elements that trigger user engagement. When this threshold is met, an email will be sent to the user and their manager asking for authorization of RDP activity. If the RDP activity is not authorized by the user, the investigation's final verdict will be deemed a "True Positive".

Deprecated. Use Cloud IAM User Access Investigation instead. Investigate and respond to Cortex XSIAM alerts where an AWS IAM user`s access key is used suspiciously to access the cloud environment.
The following alerts are supported for AWS environments.

• Penetration testing tool attempt
• Penetration testing tool activity
• Suspicious API call from a Tor exit node
  This is a beta playbook, which lets you implement and test pre-release software. Although AWS is supported, we are working towards multi-cloud support. As the playbook is beta, it might contain bugs. Updates to the playbook during the beta phase might include non-backward compatible features. We encourage feedback on the quality and usability of the content to help us identify and fix issues, so we can continually improve the content.

The Identity Analytics - Alert Handling playbook is designed to handle Identity Analytics alerts and executes the following:

Analysis:

• Enriches the Indicators and the account, providing additional context and information about these indicators.

Verdict:

• Determines the appropriate verdict based on the data collected from the enrichment phase.

Investigation:

• Checks for related XDR alerts to the user by Mitre tactics to identify malicious activity.
• Checks for specific arguments for malicious usage from Okta using the 'Okta User Investigation' sub-playbook.
• Checks for specific arguments for malicious usage from Azure using the 'Azure User Investigation' sub-playbook.

Verdict Handling:

• Handles malicious alerts by initiating appropriate response actions, including blocking malicious IP and revoking or clearing user's sessions.
• Handles non-malicious alerts identified during the investigation.

This playbook handles impossible traveler alerts.

An Impossible Traveler event occurs when multiple login attempts seen for a user from multiple remote countries in a short period of time, which shouldn't be possible. This may indicate the account is compromised.

Attacker's Goals:

Gain user-account credentials.

Investigative Actions:

Investigate the IP addresses and identities involved in the detected activity using:

• Impossible Traveler - Enrichment playbook
• CalculateGeoDistance automation

Response Actions

The playbook's first response actions are based on the data available within the alert. In that phase, the playbook will execute:

• Manual block indicators if the IP address found malicious
• Manual disable user
• Manual clear of the user’s sessions (Okta)

When the playbook continues, after validating the activity with the user’s manager, another phase of response actions is being executed, which includes:

• Auto block indicators

External Resources:

Impossible traveler alert

This playbook handles external and internal scanning alerts.

Attacker's Goals:

Adversaries may attempt to get a listing of services running on remote hosts, including those that may be vulnerable to remote software exploitation. Methods to acquire this information include port scans and vulnerability scans using tools that are brought onto a system.

Investigative Actions:

Investigate the scanner IP address using:

• IP enrichment:
• NGFW Internal Scan playbook
• Endpoint Investigation Plan playbook
• Entity enrichment

Response Actions

The playbook's response actions are based on the initial data provided within the alert. In that phase, the playbook will execute:

• Automatically block IP address
• Report IP address (If configured as true in the playbook inputs)

When the playbook executes, it checks for additional activity using the Endpoint Investigation Plan playbook, and another phase, which includes the Containment Plan playbook, is executed.
This phase will execute the following containment actions:

• Automatically isolate involved endpoint
• Manual block indicators
• Manual file quarantine
• Manual disable user

External resources:

Mitre technique T1046 - Network Service Scanning

Port Scan

This playbook is responsible for ransomware alert data enrichment and response.
The playbook executes the following:

1.Checks if the initiator is a remote attacker and allows isolating the remote host, if possible.

2.Retrieves the WildFire sandbox report and extract the indicators within it.
* The playbook tries to retrieve the report, but if there is no report available, the playbook tries to fetch the ransomware file for detonation.

3.Hunts for the ransomware alert indicators from the alert table, searches for endpoints that have been seen with them, and allows containing the identified endpoints.

This playbook handles WildFire Malware alerts.
It performs enrichment on the different alert entities and establishes a verdict.
For a possible true positive alert, the playbook performs further investigation for related IOCs and executes a containment plan.

This playbook searches XDR alerts related to specific entities, on a given timeframe, based on MITRE tactics.
Note: The playbook's inputs enable manipulating the execution flow. Read the input descriptions for details.

This playbook get as an input all of the involved IP addresses and identities from the Impossible Traveler playbook alert, and enriches them based on the following:

• Geo location
• Active Directory
• IP enrichment e.g. VirusTotal, AbuseIPDB, etc.

This trigger is responsible for handling WildFire Malware alerts

This trigger is responsible for handling "core - Large Upload" alerts

This trigger is responsible for handling T1059 - Command and Scripting Interpreter alerts

This trigger is responsible for handling T1036 - Masquerading alerts

This trigger is responsible for handling External RDP Brute-Force alerts

This trigger is responsible for XDR IOC alerts

This trigger is responsible for handling Impossible Traveler alerts

This trigger is responsible for handling alerts involving scanning activity identified by our NGFW

This trigger is responsible for handling Identity Analytics alerts

This trigger is responsible for handling ransomware alerts

This trigger is responsible for handling Remote PsExec with LOLBIN command execution alerts