Setup a Malware Incident in Cortex XSOAR - Tutorials - 6.x - Cortex XSOAR - Cortex - Security Operations

Cortex XSOAR Tutorials 6.x

Product
Cortex XSOAR
Version
6.x
Creation date
2022-09-02
Last date published
2023-04-16
Category
Tutorials

Malware (malicious software) refers to any software intentionally designed to cause damage to a single computer, server, or computer network. Malware can infect target computers through the some of the following types:

  • Virus: A type of code that when executed replicates itself by modifying other programs and inserting its own code.

  • Worm: A standalone program that replicates itself and spreads from one computer to another.

  • Trojan: Any Malware which misleads users of its true intent. Malware can also play a role in phishing attempts. For example, where users are duped into downloading and running a file on their machine, which in turn infects their machine and possibly other machines.

  • Ransomware: Threatens to publish the victim's data or perpetually block access to it unless a ransom is paid.

The following example is a typical Trojan use case through spear phishing.

An employee of an organization (David) receives a spear phishing email (previous social research shows that the employee is a fan of Marvel):

Hi Guys,

Great running into you at Black Hat last week. As promised, I located that Gag Reel from Endgame and thought you would like to have it. It’s zipped up to speed up the downtime time.

Hope you enjoy it!

Attachment gag-real-endgame.zip

David opens the email and sees it is a zip file. He extracts the zip file and clicks the attachment which he thinks is an MP4 file but it is in fact an infected file with Quasar RAT. The aim is to establish command and control to leverage control in the organization.

The attacker starts recon on the compromised host and tries to find additional targets that are most likely end-user workstations to establish multiple beachheads in case some of the endpoints are taken off line. The attacker may set up some of the compromised hosts as sacrificial lambs in case the actions are discovered. The attacker then uses commands to distribute and execute Quasar and DarkComet RAT clients to target systems.

As soon as the attacker has a strong foothold in the organization, the attacker locates the SQL Database server. The adversary copies the database backup and uses File Manager in Quasar to download the database backup to the attacker's system. The attacker deletes any files downloaded to the victim’s systems.

In this example, we use Cortex XDR to alert the user (usually it is set to block).

In Cortex XSOAR, we want to see the incident that has been ingested from Cortex XDR and to immediately assign it to an on-call tier-1 analyst who has experience in these kinds of incidents. This incident is linked to Cortex XDR.

The analyst should be able to take immediate action like blocking the IP address on the Firewall. The analyst can assign it to a tier-2 analyst to assist, who can investigate and remediate it in the Cortex XDR platform. After remediation in Cortex XDR, if relevant, you may to return to Cortex XSOAR and to disable the users that were infected and delete the email from the organization using the Search and Delete Emails - Generic playbook, which can find and delete malicious emails using EWS. If there is a Jira or Service Now ticketing system, we can set up a notification.

Cortex XSOAR has a mirroring function which enables you to make any changes in Cortex XSOAR that are added to Cortex XDR and vice versa.

Although this tutorial concentrates on Cortex XDR you can use this template as a base resource to design and implement your own automated response to a Malware incident with any EDR/XDR product.

To get up and running with a Malware incident in Cortex XSOAR, follow these stages.

Stage

Section

Description

1.

Plan Your Malware Incident

At this initial stage, consider some of the following information before installing Cortex XSOAR.

  • How are you going to ingest incidents into Cortex XSOAR?

  • What does an analyst need to investigate?

  • How to deal with the response?

  • What integrations do you need?

2.

Cortex XDR Incident Type Customization

You need to install the Palo Alto Networks Cortex XDR - Investigation and Response Content Pack. Review and customize the incident type, (including indicator extraction rules, layouts, creating fields, etc).

3.

Configure Third-Party Integrations

Install Content Packs from the Marketplace and then add your required instances. For example, we need to install the Palo Alto Networks Cortex XDR - Investigation and Response Content Pack, which includes the Palo Alto Networks Cortex XDR - Investigation and Response integration to ingest incidents, the AutoFocus Content Pack for the Palo Alto Networks AutoFocus v2 integration for data enrichment, etc.

4.

Classify and Map Cortex XDR fields

Classification enables you to have a better control of the type and structure of incoming incidents. Map the fields so you can see these fields in the incident layout.

5.

Add Pre-Process Rules

Add pre-process rules to perform certain actions on incidents as they are ingested into Cortex XSOAR. For example, drop identical incidents and link to existing incidents. We do not need to create this rule, as it comes out of the box with the Cortex XDR Incident Handling v3 playbook.

6.

Review the Cortex XDR Incident Handling v3 Playbook

Playbooks are triggered either when an incident is created or when you run them manually as part of an investigation. In this example, we use the Cortex XDR Incident Handling v3 playbook.

7.

Create Post Process Rules

Once the incident is complete and you are ready to close it, you can run various post-processing actions on the incident.

8.

Investigation

Now everything is set up, it is ready for analysts to start investigating an incident.

Plan Your Malware Incident

Before you begin, consider the following requirements:

  1. Where do your Malware incidents originate?

    In this example, we are going to ingest incidents from Cortex XDR, but maybe you use a different product, like Carbon Black or Cybereason, or you ingest incidents directly from SplunkES or QRadar, etc.

  2. What information do you want to see in an incident as part of an investigation?

    For Cortex XDR, we want to see the XDR description, incident ID, status, host count, notes, URL, Alert Count, Assigned user Pretty Name, Assigned User Email, etc. We may want to add the appropriate role to the incident (those who are on-call with experience).

    We may want to add custom fields, such as XDR Tuning, which enables the analyst to consider whether to fine tune a security policy.

    The Cortex XDR incident layout comes out of the box with fields that are necessary to investigate Malware incidents that originate from XDR. There are other layouts you can use such as Malware, Cybereason, Carbon Black, etc. All these sections and fields are fully customizable.

  3. What incident response process do you currently use?

    You may want to check Hash or the File Path, act according to the country to increase severity, block IPs, manually investigate further, close incidents, etc. We can add these steps into a playbook.

    In this example, we are going to use the out of the box Cortex XDR Incident Handling v3 playbook.

  4. What enrichment feeds do you use?

    We might want to extract specific fields, like STIX Threat Actor, CVE, Dest, Host Name, Destination IP, URL, etc.

    In this example, we are going to enrich all extracted IOCs (file, email addresses, domain enrichment) via VirusTotal and AutoFocus to hunt for IOCs.

  5. What detonation systems do you use?

    Based on the verdict of the IOC, you should use static/dynamic file analysis tools or sandbox integrations to determine the maliciousness of the file. You can run this automatically in the playbook or use it manually through a detonation integration. In this example, we will detonate malicious files using WildFire.

  6. Are there any manual steps to be taken?

    Consider which manual steps need to be taken. These steps can be added to a playbook. We want the analyst to review after triage and take any immediate action as required. At the remediation stage we may a data collection task capturing closing notes/resolve comments for XSOAR and XDR incidents respectively.

  7. Are there any end user interactive steps?

    Do you need to ask the end user questions via email, do you need management approval by email, do you need to pull another analyst, etc?

  8. Is there any duplication?

    You may want to find active incidents with a similar subject line and sender, close duplicate incidents, etc. If you want to manually query duplicate incidents, use the FindSimilarIncidents command.Automatic De-Duplication Using Scripts

    In this example, we use the deduplication logic in the Cortex XDR Incident Handling v3 playbook. This closes duplicates in Cortex XSOAR and Cortex XDR. We should if possible reference the original Cortex XSOAR and Cortex XDR Incidents in the closing notes/resolve comments (XDR).

  9. Are there any steps to be taken after closing an incident?

    After closing an incident, do you need to send a notification to a third-party service like Jira/Service Now, or verify that all tasks are done?

  10. Do you need to restrict incident investigations?

    Do you want to restrict incident actions and investigations according to roles? Do you want to give read-only access to certain roles at certain times? For example, when an incident is in triage, you may want all Tier-2 analysts to have read-only access.

Summary of Third-Party integrations

Now we have considered our requirements, these are the integrations that we are going to install:

Integration

Description

Palo Alto Networks Cortex XDR - Investigation and Response

Endpoint

EWS Mail Sender

Mail sender

VirusTotal

Palo Alto Networks Autofocus v2

Data enrichment and threat intelligence

Palo Alto Networks Wildfire v2

Forensics and Malware Analysis

Active Directory Query v2

Forensics and Malware Analysis (we may want contact or to take action on a user’s mailbox)

Rasterize

Utilities

All these integrations are in the Content Packs which can be installed from the Marketplace.

Now you have finished the planning stage, you can now set up Malware incidents in Cortex XSOAR.

Cortex XDR Incident Type Customization

You will shortly install all the relevant Content Packs in the Marketplace and then Configure Third-Party Integrations. In the first instance install the Palo Alto Networks Cortex XDR - Investigation and Response Content Pack, which contains the following:

  • Cortex XDR incident types: Contains a unique set of data that is relevant to stop network, endpoint and cloud data attacks. For this use case, we want to use the Cortex XDR incident type, so when an XDR incident is ingested into Cortex XSOAR, by default, it will use this incident type. We can customize which playbook to run, which layout, etc.

  • Cortex XDR layouts: Displays relevant data for analysts to investigate a Cortex XDR incident, port scan, violations, etc. We want to use the Cortex XDR incident type which is relevant for this use case. In the Investigation tab for this incident type, you can see information about the XDR alerts, file and network artifacts, the file image (using Rasterize), indicators, etc.

    malware-invest.png
  • Incident fields: Contains fields which assist with the Malware investigation most of which are specific to the Cortex XDR, such as XDR Alerts, XDR description, XDR status, etc., which are added to the layout.

  • Cortex XDR playbooks and sub-playbooks: Automates the Malware investigation and alert response. For example, Cortex XSR incident handling v3, Cortex XDR alerts handling, Cortex XDR Block file, etc.

  • Automations: Automations that check for number of hosts in an incident, number of users that participated in the incident, etc. Run these in a playbook or in the CLI.

  • Classifiers: Contains classifiers and mappers for Cortex XDR. For more information, see Classify and Map Cortex XDR fields.

  • Indicators: Includes the Cortex XDR status indicator field.

In this section, we need to do the following:

Customize the Cortex XDR Incident Type

A Cortex XDR incident is ingested into Cortex XSOAR and is classified as such through the Cortex XDR incident type. You can customize the layout, playbook, color, and also define the indicators to extract. Indicator extraction extracts indicators from incident fields and enriches them using commands and scripts defined for the indicator type.

  1. Select SettingsOBJECTS SETUPIncidentsTypesCortex XDR Incident.

  2. Click DetachEdit.

    When an incident type is detached, it no longer receives updates to the incident type from the Content Pack. Usually the incident type itself does receive regular updates, although the incident type, associated with the playbook may change. If you want to receive updates, duplicate the incident type instead (the original incident type receives the update and not the duplicated incident).

  3. From the Settings tab, review the following:

    • In The Default playbook field, select the Cortex XDR Incident Handling v3 playbook. This is a comprehensive playbook covering triage to remediation.

    • In the Layout field, we will keep the Cortex XDR Incident layout, but we will customize it.

      We will create a post process rule later, but for now we will leave this blank.

  4. In the Indicators Extraction tab, consider which fields you want to extract.Indicator Extraction

    By default all indicators are being extracted from all fields. We will keep this as is, but if you find your system being adversely affected, you should define specific fields to extract, such as File Hash, Destination IP, MD5, SHA256, etc.

  5. Click Save.

Review the Cortex XDR Incident Layout

It is important to build or customize the layout to ensure that you display the most relevant data for analysts at all stages of the incident life cycle. For example, we want to see Cortex XDR information (such as ID, description, severity), file information, indicators, details about the incident, etc. As part of this process we need to add any information that is not included in the layout.

You should familiarize yourself with the Cortex XDR layout, before you make any changes. You may want to create sections, add buttons, add custom fields, etc. To view the layout, go to SettingsOBJECTS SETUPIncidentsLayoutsCortex XDR Incident.

You can see the following tabs:

  • Incident Summary

    In the Incident Summary tab, there are 8 out of the box tabs. For more information about each tab, see Incident Investigation. We will concentrate on the following tabs (as these are customizable):Incident Investigation

    Case info

    This Case info tab contains a summary of all the relevant information an analyst may require about the incident (such as type, severity, playbook, etc), Cortex XDR information, timeline information (when the incident occurred, created, updated, etc.), Work plan information (such as outstanding tasks), team members, linked incidents, etc.

    malware-caseinfo.png

    Investigation

    The investigation tab contains an overview of the relevant information an analyst may require about the investigation such as XDR alerts (Alert ID, detection timestamp, severity, indicators, etc.), device control violations, etc.

    Similar Incidents

    Displays any incidents that are similar to the current incident.

  • New/Edit Form: Contains information relevant to creating or editing a Cortex XDR incident

  • Close Form: Contains information relevant to closing a Cortex XDR incident.

  • Incident Quick View: Contains summary information relating to the Cortex XDR incident.

For more information about customizing incident types generally, see Incident Customization.Incident Customization

Create Custom Fields for the Cortex XDR Incident Layout

As you have now familiarized yourself with the layout, create custom fields. These fields can then be added to the Cortex XDR incident layout. You can view and edit all existing out of the box fields in the fields table. In this example, we create the following fields:

Field Name

Field Type

Comments/Values

XDR Tuning Required?

Boolean (checkbox)

Enables the analyst to consider whether to fine tune a security policy (in the Case info tab and the Close tab.

Was a link clicked?

Boolean (checkbox)

We add this to the Case info tab and when creating or editing an incident.

Was there a High Value Target?

Boolean (checkbox)

We add this to the Case info tab and when creating or editing an incident.

  1. Go to SettingsOBJECTS SETUPIncidentsIncident Fields.

  2. Create the XDR Tuning Required field.

    1. Click New Field.

    2. In the Field Type field, select Boolean (checkbox).

    3. In the Field Name field, type the name you want to use, such as XDR Tuning Required.

    4. Click Save.

  3. Repeat for the other fields.

    As we have now created the custom fields, add these to the layout.

Customize the Cortex XDR Incident Layout

We need to add the custom fields to the Cortex XDR layout.

  1. Go to SettingsOBJECTS SETUPIncidentsLayouts.

  2. Select the Cortex XDR Incident layout checkbox.

  3. Click Detach.

    When an incident layout is detached, it no longer receives layout updates from the Content Pack. If you want to receive updates, duplicate the layout instead.

  4. Click the Cortex XDR Incident layout to edit.

  5. In the Case info tab, add the custom fields to a new section.

    We can add these custom fields to any section, and in this example, we want to create a new section.

    1. From the Library section, in the Sections tab, drop and drag the New Section onto the Case info tab.

    2. Rename the section to Quick Actions, by editing the settings.

    3. In the Fields and Buttons tab, drag and drop the custom buttons we have created.

      malware-quick.png
  6. Click the “New”/”Edit” Form tab, add the custom fields, as required.

    You can see below we have added the majority of the fields to the Basic Information section.

    malware-basic.png
  7. Click the “Close” Form tab and add the XDR Tuning Required field we created earlier to the Custom Fields section.

    malware-close.png
  8. Click Save Version.

    Save Version enables you to restore any changes.

Configure Third-Party Integrations

After customizing the phishing incident type, we need to configure third-party integrations.

  1. Go to Marketplace and install the following Content Packs (which contain the required integrations):

    Content Pack

    Integration

    EWS Mail Sender

    EWS Mail Sender

    VirusTotal

    VirusTotal

    AutoFocus

    Palo Alto Networks AutoFocus v2

    Palo Alto Networks WildFire

    Palo Alto Networks WildFire v2

    Active Directory Query

    Active Directory Query v2

    The Rasterize integration is installed out of the box.

  2. Add the Palo Alto Networks Cortex XDR - Investigation and Response integration. This integration fetches incidents from Cortex XDR.

    We have already installed the Palo Alto Networks XDR Content Pack, which includes the Palo Alto Networks Cortex XDR Investigation and Response integration.

    1. In Cortex XDR:

      1. Generate the API Key and API Key ID by clicking SettingsIntegrationsAPI Keys.

      2. Click New Key .

      3. In the Security Level field, select Advanced.

      4. In the Role field, select Instance Administrator.

      5. Click Save.

      6. Copy the API key.

      7. Copy the ID from the API keys table.

      8. Click Copy URL.

        malware-xdr-api.png
    2. In Cortex XSOAR:

      1. Add the Cortex XDR instance by selecting SettingsINTEGRATIONSAdd instance.

      2. Select Fetches incidents.

      3. Add the Server URL, API Key ID, and the API Key.

      4. Click Test and then click Save & exit.

        malware-int.png

      Incidents are now ingested from Cortex XDR into Cortex XSOAR.

  3. Add the EWS Mail Sender integration, which sends emails to users.

    1. Click Add instance.

    2. Add the Exchange URL or Server IP address, Authentication, and Password. The Server Version is 2013 and the Authentication Type is Basic (Office 365).

    3. Click Test and then Save & exit.

      phishing-ewsend.png
  4. Add the VirusTotal instance, which investigates suspicious files, domains, URLs, IP addresses, etc.

    1. Click Add instance.

    2. Add the API Key.

    3. Click Test and then Save & exit.

  5. Add the Palo Alto Networks AutoFocus v2 instance which investigates suspicious files, domains, URLs, IP addresses, etc.

    1. Click Add instance.

    2. Add the API Key.

    3. Click Test and then Save & exit.

  6. Add the Palo Alto Networks WildFire v2 instance, which submits files and returns the report plus looking up the file reputation.

    1. Click Add instance.

    2. Add the Server base URL and API key.

    3. Click Test and then Save & exit.

  7. Add the Active Directory Query v2 instance, which accesses and manages Active Directory objects (users, contacts, and computers) and runs AD queries.

    1. Click Add instance.

    2. Add the Server IP address, Port, Credentials, Password, and Base DN.

    3. Click Test and then Save & exit.

  8. Add the Rasterize integration, which converts URLs, PDF files, and emails to an image file.

    1. Click Add instance.

    2. Click Test and then Save & exit.

Classify and Map Cortex XDR fields

Classification determines the type of incident that is created for events ingested from a specific integration (Cortex XDR). Mapping matches the fields from your 3rd party integration to the fields that you defined in your Cortex XDR incident type layout.

Cortex XDR comes out of the box with the following:

  • Cortex XDR classifier

  • Cortex XDR Incoming Mapper (maps data from Cortex XDR to Cortex XSOAR)

  • Cortex XDR Outgoing Mapper (maps data from Cortex XSOAR to Cortex XDR)

Cortex XSOAR uses mirroring so that any changes made to XSOAR/XDR are mirrored in each environment.

As we are ingesting incidents from a Cortex XDR, we do not need to change the classifier, as everything that is ingested into Cortex XSOAR is from Cortex XDR is classified as a Cortex XDR incident type. If there were other third-party integrations that you fetched incidents from such as Qradar you may need to update the classifier.

Map incident fields

  1. Select SettingsOBJECTS SETUPIncidentsClassification & MappingCortex XDR - Incoming Mapper checkbox.

  2. Click Duplicate.

  3. Open Cortex XDR - Incoming Mapper_copy.

  4. In the Incident Type field, select Cortex XDR Incident.

  5. In the Select Instance field, select your Cortex XDR configured instance.

    On the left side of the screen you see all of the fields that are available for the Cortex XDR incident type. We can see that some fields are already mapped, such as XDR Alerts, XDR Description, Occurred, etc.

  6. Click auto-map to automatically map fields based on naming convention. In this example, SHA256 maps to attachmentsSHA256.

    malware-map.png
  7. Map one of the system fields.

    1. For the OS Version field, click Chose data path.

    2. Click agent_os_sub_type.

    3. Click OK.

      We can see the result is Ubuntu 18.04.5 LTS.

      malware-map-os.png
    4. Repeat these steps for any custom or system fields that require mapping.

  8. For the Outgoing Mapper review the fields that are mapped.

    If you have any additional fields that you have created and map them.

    malware-outgoing.png
  9. Add the mapper to the Palo Alto Networks Cortex XDR - Investigation and Response integration settings.

    • In the Mapper (incoming) field, from the drop-down list select Cortex XDR - Incoming Mapper_copy.

    • If relevant, in the Mapper (outgoing) field from the drop-down list, select Cortex XDR - Outgoing Mapper_copy.

Pre-process Rules

Although we have started ingesting incidents into Cortex XSOAR, you may get a number of Cortex XDR incidents that are identical. Rather than ingesting all these incidents, we can drop or close these incidents and link them to an existing incident, which can save an analyst a substantial amount of time.

Pre-Process Rules enable you to perform certain actions on incidents as soon as they are ingested into Cortex XSOAR directly from the user interface.Create Pre-Process Rules for Incidents

The Cortex XDR Incident Handling v3 playbook has inbuilt pre-processing rules to remove duplicate incidents, so we do not need to add any at this stage.

Review the Cortex XDR Incident Handling v3 Playbook

The Cortex XDR Incident Handling v3 playbook is triggered after fetching an incident from the 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. The playbook subsequently 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 remediation, if there are no new alerts, the playbook stops the alert sync and closes the XDR incident and investigation. The playbook uses the incoming and outgoing mirroring feature so any changes are mirrored in Cortex XDR and vice versa.

After the Calculate Severity - Generic v2 sub-playbook runs, Cortex XSOAR is treated as the single source for the severity field. It syncs from Cortex XSOAR to XDR, so any manual changes for the severity field are reflected in Cortex XDR.

The playbook uses the following sub playbooks:

  • Calculate Severity - Generic v2

  • Cortex XDR Alerts Handling

  • Cortex XDR device control violations

  • Block Indicators - Generic v2

  • Entity Enrichment - Generic v3

  • Palo Alto Networks - Hunting And Threat Detection

Customize the Cortex XDR Incident Handling v3 Playbook

In this example, we use the Cortex XDR Incident Handling v3 playbook, as this is a comprehensive playbook and uses numerous playbooks which are all interlinked to create a complete cycle from detection to remediation.

  1. Go to Playbooks and search for Cortex XDR Incident Handling v3.

  2. To edit the playbook (add/delete tasks, sub-playbooks, or the flow, etc) click detach playbook.

    You can duplicate rather than detach if you want to receive content updates for the playbook.

  3. Review and change the playbook inputs by clicking Playbook Triggered.

    1. In the Inputs tab, review the inputs.

      For example, the playbook finds similar incident fields, and links them, whether to hunt for related IOCs, define critical users in your organization, and critical endpoints, etc. You can change these if required.

      Auto remediation is turned off by default.

    2. Click Save (if required).

    In the Cortex XDR - get incident extra data task, the playbook retrieves data from Cortex XDR, such as description, alert count, alert details, such as severity, external ID, etc. For example:

    malware-pb-task.png
  4. Review the deduplication stage.

    The playbook looks for similar incidents based on the Cortex XDR description.

    If there are similar incidents, the user can decide whether to manually close the incident as duplicate, otherwise the playbook continues to run.

    If you do not want to link similar incidents, or change how it links the incidents (based on description) edit the settings in the playbook inputs (see step 3.2 above).

  5. Review the Alerts handling stage.

    The playbook runs the Cortex XDR Alerts handling sub-playbook.

    As the incident will be Malware, the sub-playbook uses the Cortex XDR Malware Investigation playbook, which does the following:

    • Enriches the infected endpoint details

    • Let the analyst manually retrieve the malicious file

    • Performs file detonation (if manually retrieved from Cortex XDR), which provides details about file reputation. Any sandbox integrations that you have enabled will run and provide details about the file reputation. In this example, we use Wildfire.

  6. Review the Investigation stage.

    After retrieving the Cortex XDR count alerts, the playbook uses the Cortex XDR device control violations playbook to query Cortex XDR for device control violations for the specified hosts, IP address, or XDR endpoint ID.

    If device control violations were found, communication via email with involved users is undertaken to understand the nature of the incident and if the user connected the device. We use Active Directory and EWS integrations to communicate.

    In the Communicate with the end-user task, a number of questions are sent to the end user. In Question 1, we will change the question to Did you connect the device? and we will add a Don’t know response.

    malware-pb-connecttask.png

    All the collected data is displayed in the XDR device control incident layout.

  7. Review indicator enrichment.

    After extracting indicators from a file and a detonated file (if there is a file attachment) we need to enrich the indicators. This gives us additional information about the indicators that have been extracted. We use the following sub-playbooks:

    • File Enrichment - Generic v2: Enriches the file using VirusTotal Private API or whether there is a SHA256 hash and enriches the file using Cylance Protect v2.

    • Email Address Enrichment - Generic v2.1: Provides information whether an email address is internal or external. It uses Active Directory to provide extra information about the user, checks for domain squatting (such as using a similar domain).

    • IP Enrichment - External - Generic v2: Checks whether there are internal and external IP addresses and enriches external IP addresses using VirusTotal or Threat Crowd.

    • URL Enrichment - Generic v2: Checks for URLs, enriches through VirusTotal Private API, verifies SSL & captures screenshots using the Rasterize integration.

    • Account Enrichment - Generic v2: Checks whether an account be enriched using Active Directory.

    • Endpoint Enrichment - Generic v2.1: Checks host information from Active Directory, McAfee, Black Enterprise, etc.

    • CVE Enrichment - Generic v2.1: Gets CVE information using VulDB, CVE Search, or IBM XFE.

    • Domain Enrichment - Generic v2: Checks for a domain using either Cisco Umbrella or VirusTotal Private API.

    As we use VirusTotal, and Active Directory, there is no need to customize these sub-playbooks. If you use different enrichment integrations these need to be added. These playbooks add to the DBot score (reputation of the indicator).

  8. Review the investigation stage.

    1. If you select hunt for IOCs (in the Playbook Triggered inputs), the Palo Alto Networks - Hunting and Threat Detection playbook queries samples, sessions and tags, using Autofocus, PAN-OS, etc. The playbook receives inputs based on hashes, IP addresses, or domain names provided manually or from outputs by other playbooks. In this case, with the received indicators, the playbook uses data received by Autofocus to search for IP addresses, host names and users related to the provided indicators.

      The output facilitates searches for possibly affected IP addresses or users.

    2. Calculate Severity - Generic v2 Sub-Playbook

      The playbook calculates and assigns the incident severity based on the highest returned severity level from the following calculations:

      1. Authenticity of the email (whether it passed the authenticity check).

      2. Calculates the severity of the critical assets according to the Calculate Severity - Critical Assets v2 sub-playbook. This playbook checks critical users, critical user groups, critical groups, critical endpoint groups or critical endpoints. You can define the critical users in your organization by editing the inputs (see step 3.2). If one critical entity is involved in the incident, it will raise the severity to critical.

      3. The current incident severity - (if it already has a severity level).

      4. The DBot Score from tasks that run in this playbook, (like from indicators, critical endpoints, critical users, critical groups, accounts, endpoints, email authenticity checks, etc.).

    The incident severity is determined by the highest returned score.

    malware-sev.png
  9. Review the Remediation Process

    The last part of the process is remediation. We have 2 options:

    • Use the Block Indicators - Generic v2 sub-playbook, which blocks IPs, files, accounts, and URLs. For example, for IPs it blocks IP addresses using MineMeld, Zscaler, etc. Customize it using your own integration.

    • Manually remediate the incident.

    To choose the remediation method, go to the Playbook Triggered task (at the beginning of this playbook) and enter the value (true or false). We have selected to Manually remediate the incident.

    The analyst can now consider blocking ports (if a block port alert was investigated) and whether there are any new non-handled alerts. If not, the incident is closed.

Create Post Process Rules

After you remedy an incident, you may want to perform additional actions on the incident, such as closing a ticket in a ticketing system such as Service Now or sending out an email, verifying all tasks are completed, etc. You can Create a Post-Process Script to cover as many scenarios as you need.Post Processing for Incidents

In this example, when closing an incident we want to update automatically the owner of the incident to the user who closes it. This user is responsible for any post closure issues.

  1. Create a script in the Automation page.

    1. Click Upload Automation.

    2. Upload the following script.

      commonfields:
        id: Close Incident by User ID
        version: 1
      contentitemexportablefields:
        contentitemfields:
          packID: ""
          itemVersion: ""
          fromServerVersion: ""
          toServerVersion: ""
          propagationLabels:
          - all
      vcShouldKeepItemLegacyProdMachine: false
      name: CloseIncidentbyUserID
      script: |-
        result = (demisto.args())
        demisto.executeCommand("setIncident", {'owner': result['closingUserId']})
      type: python
      tags:
      - post-processing
      enabled: true
      scripttarget: 0
      subtype: python2
      pswd: ""
      runonce: false
      runas: DBotWeakRole

      Ensure that the post-processing tag is selected.

      phishing-process.png
    3. Click Save Version.

  2. Add the automation to the Cortex XDR Incident type.

    1. Select SettingsOBJECTS SETUPIncidentsTypesCortex XDR IncidentEdit.

    2. In the Post-process using field, select CloseIncidentbyUserID.

    3. Click Save.

    When a user closes an incident, the user who closed the incident now becomes the owner. When an incident is reopened. the user who closed the incident will be able to keep track of reopened incidents.

Investigation

Now that everything is set up, you are now ready for an analyst to use Cortex XSOAR. Go to incidents and select a Cortex XDR incident. In the Case info tab you can see out of the box and the customized sections. In the Investigations tab, you see the information that was populated. Change and update as necessary until you have the required information.

malware-investigation.png