Core - Investigation and Response

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

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.

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.

Default layout

This playbook is designed to handle the following alerts:

• Windows Event Log was cleared using wevtutil.exe
• Security Event Log was cleared using wevtutil.exe
• A Sensitive Windows Event Log was cleared using wevtutil.exe
• Windows event logs were cleared with PowerShell
• Suspicious clear or delete security provider event logs with PowerShell
• Suspicious clear or delete default providers event logs with PowerShell
• Windows event logs cleared using wmic.exe

The playbook executes the following stages:

Investigation:
Check the following parameters to determine if remediation actions are needed:

• Cortex XSIAM alerts related to the hostname by MITRE tactics indicating malicious activity.
• Whether the CGO or the OSParent process is unsigned.
• The prevalence of the OSParent process.

Remediation:

• Handles malicious alerts by terminating the relevant processes.
• Handles non-malicious alerts identified during the investigation.

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 designed to handle the following alert:

• A successful login from TOR

The playbook executes the following stages:

Triage:

• The playbook will fetch the user identity details.

Remediation & Eradication:

• The playbooks will suggest several actions for the analyst to take: disabling the user account using Active Directory or Azure Active Directory, expiring the user password using Active Directory, or blocking traffic from TOR exit nodes using PAN-OS and Palo Alto Networks' predefined EDL.

The analyst can select multiple actions, which will then be executed by the playbook based on the analyst's choices.

Requirements:
For any response action, you will need one of the following integrations: Azure Active Directory Users / Active Directory Users.

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)

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.

This playbook is designed to handle the following alerts:

• A successful SSO sign-in from TOR
• A successful SSO sign-in from TOR via a mobile device

The playbook executes the following stages:

Early Containment:

• The playbooks will perform early containment actions by clearing\revoking user sessions and enforcing re-authentication to terminate the connection from the Tor exit node and verify the user's identity.
  Depending on the alert source, the playbook will use either
  Azure Active Directory Users or Okta v2 integrations to clear the user sessions.

Investigation:
During the alert investigation, the playbook will perform the following:

• Checks the user's risk score.
• Search for suspicious user agent usage within the alert.
• Search for related XDR alerts using the following MITRE techniques to identify any malicious activity:
  T1566 - Phishing
  T1621 - Multi-Factor Authentication Request Generation
  T1110 - Brute Force
  T1556 - Modify Authentication Process

Remediation:

• Remediation actions will be taken if the user’s risk score is high, a suspicious user agent is detected, or a related alert is found. In such cases, the playbook will disable the account.
  By default, account disabling requires analyst approval.

Requires:
For any response action, you will need one of the following integrations: Azure Active Directory Users / Okta v2.

This playbook is designed to handle the alert "Scheduled task created with HTTP or FTP reference".

The playbook executes the following stages:

Investigation:
During the alert investigation, the playbook will perform the following:

• Checks the IP and the URL reputation.
• Checks the CGO process signature.
• Searches for related XDR agent alerts to determine if the creation of the scheduled task is part of an attack pattern.

Remediation:

• Remediation actions will be taken if the CGO process is unsigned, the IP or URL has a malicious reputation, or a related alert is detected. In these cases, the playbook will disable the scheduled task, block the malicious indicators, and close the alert.

Requires: To block the malicious URL and IP, configure 'Palo Alto Networks PAN-OS' integration.

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 Incident 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 addresses the following alerts:

• Suspicious Hidden User Created

Playbook Stages:

Triage:

• Retrieve event information about the created user

Investigation:

• Check if the user is local or domain.
• For domain users: Retrieve AD attributes, including password expiration.
• For local users: Run a Powershell command to get "Password Expires" attribute of the local user.
• Get risk level for the affected host.
• Search for related Script Engine Activity alerts in the incident.

Containment:

• For alerts determined to be true positives, suggest to the analyst to disable the user.
• Upon analyst approval: Disable the suspicious user account (domain or local).
• If a related alert about malicious activity exists, kill the Causality Group Owner (CGO) process that created the suspicious user.

Requirements:

For response actions, you need the following integrations:

• Cortex Core - Investigation and Response
• Active Directory Query v2 (for domain user actions).

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.

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 is designed to handle the following alerts:

• Command-line arguments match Mimikatz execution
• Mimikatz command-line arguments
• Credential dumping via wce.exe
• Credential dumping via gsecdump.exe
• PowerShell runs with known Mimikatz arguments
• Hash cracking using Hashcat tool
• Credential dumping via fgdump.exe
• Credential dumping via LaZagne
• Credential dumping via pwdumpx.exe
• Dumping lsass.exe memory for credential extraction
• Memory dumping with comsvcs.dll

The playbook executes the following stages:

Early Containment:

• Handles malicious alerts by terminating the causality process.

Remediation:

• Handles malicious alerts by suggesting the analyst to isolate the endpoint.

This playbook addresses the following alerts:

• Unsigned and unpopular process performed injection into a commonly abused process
• Unsigned and unpopular process performed process hollowing injection
• Unsigned and unpopular process performed queue APC injection
• Unsigned and unpopular process performed injection into a sensitive process
• Unsigned and unpopular process performed injection into svchost.exe

Playbook Stages:

Triage:

• Retrieve all alerts associated with the case for initial analysis.

Early Containment:

• Identify whether an agent prevention rule was triggered for the same process ID. If so, there is high confidence that the alert is malicious.
  • If triggered in prevent mode: This indicates a high-confidence verdict and the playbook proceeds with endpoint isolation.
  • If triggered in report mode: This also indicates a high-confidence verdict. The playbook will notify the customer, advise an update to prevent mode for better protection in the future, and proceed with the investigation.
  • If no rule is triggered: The playbook will continue with additional checks to ensure thorough assessment.

Investigation:

• Check for commonly triggered alerts that often precede process injection:
  • If found, initiate containment.
  • If not found, proceed with additional checks.
• Analyze if any alerts align with MITRE ATT&CK tactics TA0004 (Privilege Escalation) and TA0005 (Defense Evasion):
  • If matching tactics are found, initiate containment.
  • If not, proceed with further investigation.
• Determine if the causality (parent) process is signed:
  • If signed by a trusted authority, close the alert.
  • If unsigned, escalate for manual approval for containment.

Containment:

• For alerts validated as threats, execute the following actions:
  • Terminate the causality process (CGO) if deemed malicious.
  • Isolate the endpoint in high-risk scenarios to prevent further compromise.

Requirements:

For response actions, you need the following integrations:

• Cortex Core - Investigation and Response.

This playbook is designed to handle the following alerts:

• Possible LDAP enumeration by unsigned process.
• Suspicious LDAP search query executed.

The playbook executes the following stages:

Investigation:
Check the following parameters to determine if remediation actions are needed:

• Cortex XSIAM alerts related to the hostname by MITRE tactics indicating malicious activity.
• Whether the Actor Process Command line contains suspicious arguments.
• Checks for prevalence of the Actor Process Name and Actor Process CMD.
• Host risk score is "Medium" or "High".
• User risk score is "High".

Remediation:

• Handles malicious alerts by terminating the causality process.
• Handles non-malicious alerts identified during the investigation.

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

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 handles "Suspicious process execution by scheduled task on a sensitive server" alerts.

Playbook Stages:

Analysis:

• Checks the suspicious process reputation.

Investigation:

• Searches for related XSIAM agent alerts to identify any malicious activity on the server.

Remediation:

If the suspicious process reputation is malicious, or if a related alert is found, the following remediation actions will be taken:

• Disable the scheduled task responsible for executing the process.
• Terminate the malicious process.
• Automatically Close the alert.

This playbook addresses the following alerts:

• A mail forwarding rule was configured in Google Workspace.
• A mail forwarding rule was configured in Google Workspace to an uncommon domain.

Playbook Stages:

Triage:

• The playbook retrieves the caller's IP, the forwarding email address, and associated filters.

Early Containment:

• The playbook checks if the IP or domain of the forwarding email address is malicious. If so, it suggests blocking the IP using PAN-OS while continuing the investigation in parallel.

Investigation:

• The playbook verifies if the rule was created outside of working hours or from an unusual geolocation and extracts suspicious keywords from the forwarding rules. It then aggregates all evidence collected during the investigation.

Containment:

• If only one suspicious evidence is found, the playbook executes soft response actions, including signing the user out and deleting the forwarding email address from the user account mailbox. The user will be notified of these actions via email.
• If multiple suspicious evidences are found, the playbook executes both soft and hard response actions, recommending the analyst suspend the user account.

Requirements:

For any response action, you need one of the following integrations:

• Gmail integration to fetch filters and remove the forwarding email address.
• Google Workspace Admin access to sign out and suspend the user account.

This playbook addresses the following alerts:

• Excessive user account lockouts
• Excessive account lockouts on suspicious users
• Excessive user account lockouts from a suspicious source

The playbook investigates and responds to excessive user account lockout alerts. It gathers information about the alert, enriches relevant host data, and analyzes event patterns. This analysis helps distinguish between benign lockouts and lockouts caused by brute-force or password spray attacks.

Playbook Stages:

Triage:

• The playbook enriches the alert with details about the lockout events.

Investigation:

• Analyzes the lockout event timestamps to detect patterns.
• Checks for related medium severity brute-force alerts in the incident.
• Retrieves the Risk Score for the Caller Computer that caused the lockouts.

Containment:

• With analyst approval, the playbook can isolate the endpoint (either the Caller Computer or the target host) if it's determined to be a true positive and not a server.

Requirements:

• For response actions, the following integration is required: Core - IR.

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 addresses the following alerts:

• User rejected numerous SSO MFA attempts
• Multiple SSO MFA attempts were rejected by a user with suspicious characteristics

Playbook Stages:

Triage:

• The playbook checks the IP address reputation associated with the MFA attempts and gathers related login events.

Early Containment:

• If the IP address is identified as malicious, the playbook blocks the IP. The investigation continues in parallel to this phase.

Investigation:

• The playbook performs an in-depth analysis, including:
  • Assessing the user's risk score to identify potentially compromised accounts.
  • Checking for an unusually high number of invalid credential attempts, which may indicate brute-force or credential-stuffing activity.
  • Verifying whether Okta logs indicate a malicious source IP based on Okta's threat intelligence.
  • Reviewing whether there have been an excessive number of MFA rejections from the user, suggesting potentially compromised behavior.
  • Looking for abnormal user agent patterns that may indicate suspicious or compromised access methods.
  • Investigating previous failed Okta login attempts within a specified timeframe to identify patterns.

Containment:

• If suspicious activity is confirmed, the playbook initiates the following containment actions:
  • Clears the user's active sessions and expires their password to prevent further unauthorized access.
  • If a successful login attempt was also detected, the playbook prompts a manual task for an analyst to review and decide on further action.

Requirements:
For any response actions, the following integration is required:

• Okta v2

For early containment actions, the following integration is required:

• Palo Alto Networks PAN-OS.

This playbook is designed to handle the following alerts:

• Netcat makes or gets connections

The playbook executes the following stages:

Analysis:

• Investigate the IP and Domain reputation
• Search previous similar alerts

Remediation:

• Handles malicious alerts by terminating the causality process.

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

Analysis:

• Enriches the IP 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 addresses the following alerts:

• Uncommon creation or access operation of sensitive shadow copy by a high-risk process

Playbook Stages:

Triage:

• Check if the causality process image (CGO) is signed or not

Investigation:

• If CGO is unsigned:
  • Check the CGO process prevalence
  • Check if the process image path is common
• If CGO is signed:
  • Check process image name
  • Check initiating process image name
  • Check if username is SYSTEM
  • Check if host is a server
  • Check for previous similar alert closed as False Positive

Containment:

• Terminate causality process (CGO) process - when a signed high-risk process or an unsigned process from an uncommon path attempting to create or access sensitive shadow copy data.

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 incident, as identified by the Cortex Core - IR integration's ITDR module.
• Risky Host - one or more risky hosts are involved in the incident, 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 addresses the following alerts:

• External Exchange inbox forwarding rule configured.
• Suspicious Exchange inbox forwarding rule configured.
• Suspicious Exchange email-hiding inbox rule.

Playbook Stages:

Triage:

• The playbook retrieves the caller's IP, the forwarding email address, and the domain.

Early Containment:

• The playbook checks if the IP or domain of the forwarding email address is malicious. If so, it suggests blocking the IP using PAN-OS while continuing the investigation in parallel.

Investigation:

• The playbook checks for suspicious behaviors, including whether an Exchange admin created the rule outside of working hours, from unusual geolocation, or if the user who created the rule has a high-risk score. It then aggregates all evidence collected during the investigation.

Containment:

• If at least two suspicious pieces of evidence are found, the playbook executes soft response actions, including signing the user out and deleting the forwarding email address from the user account mailbox. The user will be notified of these actions via email.
• If more than two pieces of suspicious evidence are found, the playbook will initiate hard response actions. These include disabling the user and removing the forwarding email address from their mailbox. The user will be notified of these actions via email.

Requirements:

For any response action, you need the following integrations:

• EWS Extension Online Powershell v3 integration.
• Azure Active Directory Users.

This playbook addresses the following alerts:

• SSO Brute Force Threat Detected
• SSO Brute Force Activity Observed

Playbook Stages:

Triage:

• The playbook checks the IP reputation and fetches the events related to the brute force login attempts.

Early Containment:

• The playbook checks if the IP is suspicious. If it is, the playbook suggests blocking the IP using PAN-OS. The investigation continues in parallel to this phase.

Investigation:

• The playbook assesses the risk score of the user who successfully logged in after a brute force attempt, examines the legitimacy of the user agent and if the brute force attempt is likely automated based on the timestamp interval. It also verifies if the user has MFA configured when the alert source is Okta.

Containment:

• If there is a successful login attempt and the user's risk score is high, or if the user agent is detected as suspicious, or if the time intervals indicates that the login attempts is likely automated, the playbook clears the user's session. If the user doesn't have MFA configured, the playbook recommends expiring the user's password. If there is no successful login detected, no action is taken.

Requirements:

For any response action, you need one of the following integrations:

• Microsoft Graph User
• Okta v2

For eradication step, you need the following integration:

• Palo Alto Networks PAN-OS.

This playbook handles "Uncommon remote scheduled task created" alerts.

Playbook Stages:

Analysis:

• The playbook checks if the remote IP is external or has a bad reputation.

Investigation:
During the alert investigation, the playbook will perform the following:

• Searches for related XSIAM alerts on the endpoint that use the following MITRE techniques to identify malicious activity: T1202 - Indirect Command Execution, T1021 - Remote Services.
• Searches for related XSIAM agent alerts on the remote endpoint, to determine if the creation of the scheduled task is part of an attack pattern.
• Searches for suspicious command-line parameters indicating a malicious scheduled task.

Remediation:

• Automatically disable the malicious scheduled task.
• Block the malicious IP (requires analyst approval).
• Automatically Close the alert.

Requirements:

For response actions, the following integrations are required:

• PAN-OS.

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 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".

This playbook handles "Uncommon remote scheduled task creation" alert, which is generated on the source host that created the remote scheduled task.

Playbook Stages:

Analysis:

• The playbook verifies whether the causality process is signed and prevalent. If the process is not signed and not prevalent, it proceeds with remediation actions; otherwise, it continues investigating the alert.

Investigation:

During the alert investigation, the playbook will perform the following:

• Searches for related Cortex XSIAM alerts on the endpoint that use the following MITRE techniques to identify malicious activity: T1202 - Indirect Command Execution, T1021 - Remote Services.
• Searches for related Cortex XSIAM agent alerts on the remote endpoint, to determine if the creation of the scheduled task is part of an attack pattern.
• Searches for suspicious command-line parameters indicating a malicious scheduled task.

Remediation:

• Automatically disable the malicious scheduled task on the remote host.
• Automatically terminate the causality process.
• Automatically close the alert.

This playbook is designed to handle the following alerts:

• Suspicious SaaS API call from a Tor exit node
• Suspicious SaaS API call from a Tor exit node via a mobile device
• Suspicious API call from a Tor exit node
• Suspicious Kubernetes API call from a Tor exit node

Playbook Stages:

Early Containment:

• To terminate the connection from the Tor exit node, the playbook will clear/revoke the user's sessions and force re-authentication. Depending on the alert source, the playbook will use either MS-Graph or G-Suite to clear the user sessions.

Investigation:

• The playbook will assess the risk score of the user connected from the Tor exit node and examine the legitimacy of the user agent.

Containment:

• If the user's risk score is high or the user agent is detected as suspicious, the playbook will recommend blocking the account connected from the Tor exit node. The playbook will use MS-Graph, G-Suite, or AWS-IAM, depending on the alert source.

Eradication:

• For users with PAN-OS enabled, the playbook will recommend blocking all IPs from the Palo Alto Intelligence-based external dynamic list that contains Tor exit nodes. The goal is to prevent the use of Tor within the organization.

Requirements:

For any response action, you will need one of the following integrations:

• Microsoft Graph User
• G-Suite Admin
• AWS-IAM.

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

This playbook is designed to handle the alert
'User added to local administrator group using a PowerShell command'

The playbook executes the following stages:

Investigation:
Check the following parameters to determine if remediation actions are needed:

• Cortex XSIAM alerts related to the hostname by MITRE tactics indicating malicious activity.
• Whether the process is unsigned.

Remediation:
Handles malicious alerts by terminating the relevant processes and requesting the analyst's approval to remove the user from the local Administrators group.
Handles non-malicious alerts identified during the investigation.

This playbook is designed to handle the 'Unprivileged process opened a registry hive' alert.

Playbook Stages:

Investigation:

During the alert investigation, the playbook will perform the following:

• Checks the prevalence of the unprivileged process that triggered the alert.
• Checks the prevalence of the command line used by the unprivileged process.
• Searches for additional suspicious Cortex XSIAM alerts within the same incident in order to determine whether a remediation measure is required.

Remediation:

• To prevent malicious activity from continuing, the playbook terminates the causality processes that triggered the alert.

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

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

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 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 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 is designed to handle the following alerts:

• SSO Password Spray Threat Detected
• SSO Password Spray Activity Observed
• SSO Password Spray Involving a Honey User

Playbook Stages:

Triage:

• The playbook checks the IP reputation and fetches the events related to the SSO login attempts.

Early Containment:

• The playbook checks if the IP is suspicious. If it is, the playbook suggests blocking the IP.

Investigation:

• The playbook assess the risk score of the user who successfully logged in and examines the legitimacy of the user agent. It verifies if the user has MFA configured and analyzes the timestamps of the login attempts to detect potential malicious automated patterns.

Containment:

• If there is a successful login attempt and the user's risk score is high, or if the user agent is detected as suspicious, or if the time intervals were automated, the playbook clears the user's session. If the user doesn't have MFA, the playbook recommends expiring the user's password.

Requirements:

For any response action, you need one of the following integrations:

• Microsoft Graph User
• Okta

This playbook is designed to handle the following alerts:

• External Login Password Spray
• Successful External Login Password Spray
• External Login Password Spray on a Domain Controller
• External Login Password Spray Involving a Honey User
• Successful External Login Password Spray on a Domain Controller
• Successful External Login Password Spray on a sensitive server

The playbook is designed to investigate and respond to external login password sprays. It enriches the external IP to enable early containment, retrieves event information, and determines how the attack was carried out and whether it was successful.

Playbook Stages:

Early Containment:

• With analyst approval, the playbook will block the malicious external IP address involved in the password spray attack, limiting the attacker's ability to continue their actions.

Investigation:

• The playbook analyzes the timestamps of the login attempts to detect patterns, checks whether any logons were successful, and retrieves the Risk Score for users who successfully logged in as part of the attack.

Containment:

• Based on the user’s risk level, the playbook will expire the user’s password to prevent further unauthorized access and terminate any active RDP sessions for the affected user.

Requirements:

• For response actions, the following integrations are required: Active Directory (AD), PAN-OS, Core - IR.

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 addresses the following alert:

• Rare successful guest invitation in the organization

Playbook Stages:

Triage:

• Gather initial information about the invited user and associated alerts.

Investigation:

• Check IOCs Reputation:
  • Analyze the reputation of IP addresses, email addresses, and domains related to the incident.
• Check for Azure Alerts:
  • Retrieve user Principal Name (UPN).
  • Extract recent Azure security alerts for the inviting user.
• Check if User is Risky:
  • Assess the risk score of the inviting user based on Core and Azure risk indicators.
  • Investigate reasons behind any identified risks, including recent detections.

Containment:

• Provide a manual task for an analyst to review the findings and decide the next steps.
• Possible actions:
  • Disable the invited user.
  • Disable the inviting user.
  • Disable both users.
  • Take no action.
• If users are disabled, revoke their active sessions to ensure immediate containment.

Requirements:
For the best results, it's recommended to ensure these integrations are configured and working:

• Cortex Core - Investigation and Response for Core user risk evaluation.
• Azure Risky Users for retrieving user risk scores.
• Microsoft 365 Defender for advanced hunting queries and Azure security alerts.
• Microsoft Graph User for disabling accounts and revoking sessions.

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

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

This trigger runs the Exchange forwarding rule alerts playbook, which handles the External Exchange inbox forwarding rule configured, Suspicious Exchange inbox forwarding rule configured and Suspicious Exchange email-hiding inbox rule alerts.

This trigger is responsible for handling T1036 - Masquerading alerts

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

This trigger is responsible for handling the 'A Successful login from TOR' alert

This trigger is responsible for handling WildFire Malware alerts

This trigger is responsible for handling 'Uncommon remote scheduled task created

This trigger is responsible for handling the 'Credential Dumping using a known tool' alerts

This trigger is responsible for handling the 'SSO Brute Force Threat Detected' and 'SSO Brute Force Activity Observed' alerts

This trigger is responsible for handling 'Uncommon remote scheduled task creation' alerts

This trigger is responsible for handling the 'Suspicious LDAP search query executed' and 'Possible LDAP enumeration by unsigned process' alerts via the 'Suspicious LDAP search query' playbook

This trigger is responsible for handling 'Scheduled task created with HTTP or FTP reference' alert

This trigger is responsible for handling Suspicious SaaS Access From a TOR Exit Node

This trigger is responsible for handling External Login Password Spray attacks.

This trigger is responsible for handling the 'SSO Brute Force Threat Detected' and 'SSO Brute Force Activity Observed' alerts

This trigger is responsible for handling 'User added to local administrator group using a PowerShell command' alert

This trigger runs the A mail forwarding rule was configured in Google Workspace playbook, which handles the A mail forwarding rule was configured in Google Workspace and A mail forwarding rule was configured in Google Workspace to an uncommon domain alerts.

This trigger is responsible for handling Compromise Accounts alerts where user rejected MFA attempts.

This trigger is responsible for handling 'Suspicious process execution by scheduled task on a sensitive server' alert

This trigger is responsible for handling Impossible Traveler alerts

This trigger is responsible for handling the 'Windows Event Log Was Cleared' alerts

This trigger is responsible for handling the 'A successful SSO sign-in from TOR' and the 'A successful SSO sign-in from TOR via a mobile device' alerts

This trigger is responsible for handling alerts where a suspicious hidden user is created.

This trigger is responsible for handling Netcat Makes or Gets Connections alert

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

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

This trigger is responsible for handling ransomware alerts

This trigger is responsible for handling the 'Unprivileged process opened a registry hive' alert

This trigger is responsible for handling Valid Accounts alerts related to successful guest user invitations.

This trigger is responsible for handling 'Uncommon creation or access operation of sensitive shadow copy by a high-risk process

This trigger is responsible for handling several the 'Unsigned and unpopular process performed an injection' alerts

This trigger is responsible for handling SSO Password Spray alerts

This trigger is responsible for handling excessive user account lockouts.

This trigger is responsible for handling Identity Analytics alerts

This trigger is responsible for XDR IOC alerts