Setting up a Malware Incident in Cortex XSOAR

A tutorial that takes you through a Malware incident from the initial planning stage to investigating an incident.
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.
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.
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.
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.
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 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.
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.
Once the incident is complete and you are ready to close it, you can run various post-processing actions on the incident.
8.
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.
    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
Data enrichment and threat intelligence
Palo Alto Networks Autofocus v2
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.
  • 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
    Settings
    ADVANCED
    Incident Types
    Cortex XDR Incident
    .
  2. Click
    Detach
    Edit
    .
    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.
    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
Settings
ADVANCED
Layouts
Cortex 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):
    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.
    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.

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
    Settings
    ADVANCED
    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
    Settings
    ADVANCED
    Layouts
    .
  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.
  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.
  7. Click the
    “Close” Form
    tab and add the
    XDR Tuning Required
    field we created earlier to the Custom Fields section.
  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
    VirusTotal
    AutoFocus
    Palo Alto Networks WildFire
    Active Directory Query
    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 Responseintegration.
    1. In Cortex XDR:
      1. Generate the API Key and API Key ID by clicking on the settings icon and then clicking Settings.
      2. Click
        New Key
        and the
        Administrator Role
        .
      3. Click
        Generate
        .
      4. Copy the API key.
      5. Copy the ID from the API keys table.
      6. Click
        Copy URL
        .
    2. In Cortex XSOAR:
      1. Add the Cortex XDR instance by selecting
        Settings
        INTEGRATIONS
        Add 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
        .
      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
      .
  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
    Settings
    INTEGRATIONS
    Classification & Mapping
    Cortex 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.
  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
      .
    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.
  9. Add the mapper to the
    Palo Alto Networks Cortex XDR - Investigation and Response
    integration settings.
    • In the Mapper (incoming) field, from the dropdown list select Cortex XDR - Incoming Mapper_copy.
    • If relevant, in the Mapper (outgoing) field from the dropdown 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.
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:
  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.
    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.
  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.
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.
    3. Click
      Save Version
      .
  2. Add the automation to the
    Cortex XDR Incident
    type.
    1. Select
      Settings
      Incident Types
      Cortex XDR Incident
      Edit
      .
    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 re-opened. the user who closed the incident will be able to keep track of reopened incidents.

Investigation

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

Recommended For You