> For the complete documentation index, see [llms.txt](https://cortex-docs.paloaltonetworks.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://cortex-docs.paloaltonetworks.com/tutorials/cortex-xsoar-tutorials/readme/set-up-a-malware-incident-using-the-deployment-wizard.md).

# Set up a Malware Incident Using the Deployment Wizard

Malware (malicious software) refers to any software intentionally designed to cause damage to a single computer, server, or computer network.

Malicious entities commonly use the following malware types to infect target computers:

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

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

| Stage                                                                                                          | Description                                                                                                                                                                                                                                                                                                                             |
| -------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| [Plan Your Malware Use Case](#plan-your-malware-use-case)                                                      | <p>Before installing Cortex XSOAR, plan your malware use case by considering the following.</p><ul><li>How are you going to ingest incidents into Cortex XSOAR?</li><li>What information does an analyst need to see to help the investigation?</li><li>How to deal with the response?</li><li>What integrations do you need?</li></ul> |
| [Cortex XDR Type Customization](#cortex-xdr-incident-type-customization)                                       | Customize the Cortex XDR incident type. Install the Palo Alto Networks Cortex XDR - Investigation and Response Content Pack. Then review the incident type, including indicator extraction rules, layouts, and fields.                                                                                                                  |
| [Configure Third-party Integations](#configure-third-party-integrations)                                       | Configure third-party integrations by installing Content Packs from the Marketplace. Then add the required integration instances. For example, install the Cortex XDR - Investigation and Response Content Pack for incident ingestion and the AutoFocus Content Pack for data enrichment.                                              |
| [Classify and map Cortex XDR fields](#classify-and-map-cortex-xdr-fields)                                      | Classify and map Cortex XDR fields to control incoming incident data. Map fields to display them in the incident layout.                                                                                                                                                                                                                |
| [Add Pre-Process rules](#pre-process-rules)                                                                    | Add pre-process rules to act on incidents during ingestion. For example, drop duplicate incidents and link them to existing incidents. The Cortex XDR Incident Handling v3 playbook includes this rule.                                                                                                                                 |
| [Review the Cortex XDR Incident Handling v3 playbook](#customize-the-cortex-xdr-incident-handling-v3-playbook) | Review the Cortex XDR Incident Handling v3 playbook. Playbooks run when incidents are created or when analysts run them during an investigation.                                                                                                                                                                                        |
| [Create Post Process Rules](#create-post-process-rules)                                                        | Create post-process rules to run actions when you close an incident.                                                                                                                                                                                                                                                                    |
| [Investigation](#investigation)                                                                                | Investigate Cortex XDR incidents after completing the setup.                                                                                                                                                                                                                                                                            |

### Plan Your Malware Use Case

Before you begin, consider the following:

<details>

<summary>Where do your Malware incidents originate?</summary>

In this example, we are going to ingest incidents from Cortex XDR, but you can also use different products, like CrowdStrike Falcon or Microsoft Defender for Endpoint, or you can ingest incidents directly from SplunkES or QRadar.

</details>

<details>

<summary>What information do you want to see in an incident as part of an investigation?</summary>

For Cortex XDR, you will want to see information including the XDR description, incident ID, status, host count, notes, URL, and Alert Count. As a part of the configuration, you can choose how to assign analysts to fetched incidents (such as on-call or less busy users).

The **Malware Investigation And Response** incident layout comes out of the box with most of the fields you need to investigate Malware incidents, and it updates periodically. You may want to add custom fields, such as XDR Tuning, which enables the analyst to consider whether to fine tune a security policy. This additional information can be added by duplicating or detaching the layout, or by opening a service ticket or using AHA to request updates to the layout. If you duplicate or detach the layout, it will not receive updates.

</details>

<details>

<summary>What incident response process do you currently use?</summary>

You may want to check the file hash or the file path, block IPs, manually investigate further, and close incidents. We can add these steps into a playbook.

In this tutorial, we are going to use the out-of-the-box **Malware Investigation & Response Incident Handler** playbook.

</details>

<details>

<summary>What enrichment feeds do you use?</summary>

Cortex XSOAR provides out-of-the-box enrichment for threat intel. However, you may want to extract specific indicator fields, for example STIX Threat Actor, CVE, Dest, Host Name, Destination IP, and URL. Once the incident is ingested into the system, the playbook will extract any indicators associated with them and enrich them according to the threat intel integration installed and configured in your system.

In this tutorial, VirusTotal and AutoFocus are used to enrich all extracted IOCs (file, email addresses, domain enrichment) to hunt for IOCs.

</details>

<details>

<summary>What detonation systems do you use?</summary>

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 manually through a detonation integration such as **Palo Alto Networks WildFire v2**, **CrowdStrike Falcon Intelligence Sandbox**, or **Joe Security v2**. In this tutorial, the **Palo Alto Networks WildFire v2** integration will be used to detonate malicious files.

</details>

<details>

<summary>Are there any manual steps to be taken?</summary>

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 need a data collection task capturing closing notes/resolve comments for Cortex XSOAR and Cortex XDR incidents respectively.

</details>

<details>

<summary>Is there any duplication?</summary>

In this tutorial, we use the out-of-the-box deduplication logic in the **Dedup v4** playbook, which runs as a sub playbook in the **Cortex XDR incident handling v3** playbook. Using playbook inputs you can link or close duplicated incidents.

</details>

<details>

<summary>Are there any steps to be taken after closing an incident?</summary>

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? You can set this up with playbook inputs when configuring your use case.

</details>

<details>

<summary>Do you need to restrict incident investigations?</summary>

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.

</details>

**Summary of Third-Party Integrations**

After defining your requirements, you need to follow the Deployment Wizard to install the content packs that contain integrations with the relevant third-party vendors. See [this file](https://github.com/demisto/content/blob/master/Packs/MalwareInvestigationAndResponse/Wizards/wizard-Malware_Investigation_and_Response.json) for a full list of third-party content packs the Deployment Wizard supports.

For this tutorial, you'll need:

| Content Pack                      | Integration                                                      | Description                                                                          |
| --------------------------------- | ---------------------------------------------------------------- | ------------------------------------------------------------------------------------ |
| Cortex XDR by Palo Alto Networks  | Palo Alto Networks Cortex XDR - Investigation and Response       | Endpoint                                                                             |
| Microsoft Exchange On-premise     | EWS V2                                                           | Enables email communication with the Microsoft Office Outlook email exchange server. |
| <p>VirusTotal</p><p>AutoFocus</p> | <p>VirusTotal (API v3)</p><p>Palo Alto Networks Autofocus v2</p> | Data enrichment and threat intelligence                                              |
| Palo Alto Networks WildFire       | Palo Alto Networks Wildfire v2                                   | Forensics and Malware Analysis                                                       |
| Active Directory Query            | Active Directory Query v2                                        | Retrieve detailed information about user accounts in Active Directory                |
| Rasterize                         | Rasterize                                                        | Converts URLs, PDF files, and emails to an image file or PDF file                    |

Now that you have finished the planning stage, you can start setting 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**: Display relevant data for analysts to investigate a Cortex XDR incident, port scan, violations, etc. We want to use the Cortex XDR incident type that 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.

  |   |
  | - |

  <figure><img src="https://paloaltonetworks.fluidtopics.net/api/khub/maps/aWWAFsfQUhAJF9SNSfCzNw/resources/Tirx_LwChyUOEWMo4uY2Fg-aWWAFsfQUhAJF9SNSfCzNw/content?v=804eec066466e6e5&#x26;Ft-Calling-App=ft/turnkey-portal" alt=""><figcaption></figcaption></figure>
* **Incident fields**: Contains fields which assist with the Malware investigation, most of which are specific to Cortex XDR, such as XDR Alerts, XDR description, XDR status, etc., which are added to the layout.
* **Cortex XDR playbooks and sub-playbooks**: Automate the Malware investigation and alert response. For example, Cortex XDR incident handling v3, Cortex XDR alerts handling, Cortex XDR Block file, etc.
* **Automations**: Automations that check for the 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](/xsoar-6-administrator-guide/6.13/learn-about-cortex-xsoar/customize-and-configure-cortex-xsoar/incidents/classification-and-mapping.md).
* **Indicators**: Includes the Cortex XDR status indicator field.

In this section, we need to do the following:

* [Customize the Cortex XDR Incident Type](#customize-the-cortex-xdr-incident-type)
* [Review the Cortex XDR Incident Layout](#review-the-cortex-xdr-incident-layout)
* [Create Custom Fields for the Cortex XDR Incident Layout](#create-custom-fields-for-the-cortex-xdr-incident-layout)
* [Customize the Cortex XDR Incident Layout](#customize-the-cortex-xdr-incident-layout)

#### **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 → OBJECTS SETUP → Incidents → 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 → OBJECTS SETUP → Incidents → 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](/xsoar-6-administrator-guide/6.13/learn-about-cortex-xsoar/day-to-day-tasks-in-cortex-xsoar/incident-management/incident-investigation.md). 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.

  <figure><img src="https://paloaltonetworks.fluidtopics.net/api/khub/maps/aWWAFsfQUhAJF9SNSfCzNw/resources/XbbrggS3yk0oLG0D7wOtGA-aWWAFsfQUhAJF9SNSfCzNw/content?v=0e0a2e371b467c4c&#x26;Ft-Calling-App=ft/turnkey-portal" alt=""><figcaption></figcaption></figure>
* 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](/xsoar-6-administrator-guide/6.13/learn-about-cortex-xsoar/customize-and-configure-cortex-xsoar/incidents/incident-customization.md).

#### **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 → OBJECTS SETUP → Incidents → Incident 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 → OBJECTS SETUP → Incidents → 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 Action by editing the settings.
   3. In the Fields and Buttons tab, drag and drop the custom buttons we have created.

      <figure><img src="https://paloaltonetworks.fluidtopics.net/api/khub/maps/aWWAFsfQUhAJF9SNSfCzNw/resources/AbyOTpkgqPS16xp9F7fDkw-aWWAFsfQUhAJF9SNSfCzNw/content?v=f9da01f3e70e869a&#x26;Ft-Calling-App=ft/turnkey-portal" alt=""><figcaption></figcaption></figure>
6. Click the “New”/”Edit” Form tab and add the custom fields as required.

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

   <figure><img src="https://paloaltonetworks.fluidtopics.net/api/khub/maps/aWWAFsfQUhAJF9SNSfCzNw/resources/p896rK7q27~ndnObj1AmrQ-aWWAFsfQUhAJF9SNSfCzNw/content?v=a152db331db0537c&#x26;Ft-Calling-App=ft/turnkey-portal" alt=""><figcaption></figcaption></figure>
7. Click the “Close” Form tab and add the XDR Tuning Required field we created earlier to the Custom Fields section.

   <figure><img src="https://paloaltonetworks.fluidtopics.net/api/khub/maps/aWWAFsfQUhAJF9SNSfCzNw/resources/9DXeEqp8sBvQZ_w~QZVeyA-aWWAFsfQUhAJF9SNSfCzNw/content?v=f26b0ae770ec75bc&#x26;Ft-Calling-App=ft/turnkey-portal" alt=""><figcaption></figcaption></figure>
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](https://xsoar.pan.dev/docs/reference/integrations/ews-mail-sender)                     |
   | VirusTotal                  | [VirusTotal](https://xsoar.pan.dev/docs/reference/integrations/virus-total)                              |
   | AutoFocus                   | [Palo Alto Networks AutoFocus v2](https://xsoar.pan.dev/docs/reference/integrations/auto-focus-v2)       |
   | Palo Alto Networks WildFire | [Palo Alto Networks WildFire v2](https://xsoar.pan.dev/docs/reference/integrations/wild-fire-v2)         |
   | Active Directory Query      | [Active Directory Query v2](https://xsoar.pan.dev/docs/reference/integrations/active-directory-query-v2) |

   The [Rasterize](https://xsoar.pan.dev/docs/reference/integrations/rasterize#configure-rasterize-on-cortex-xsoar) 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](https://xsoar.pan.dev/docs/reference/integrations/cortex-xdr---ir) integration.

   1. In Cortex XDR:
      1. Generate the API Key and API Key ID by clicking Settings → Integrations → API 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.

         <figure><img src="https://paloaltonetworks.fluidtopics.net/api/khub/maps/aWWAFsfQUhAJF9SNSfCzNw/resources/aAUUjOlVDu~8ZrPgg5m7VA-aWWAFsfQUhAJF9SNSfCzNw/content?v=f3ea9d254c9d9ef9&#x26;Ft-Calling-App=ft/turnkey-portal" alt=""><figcaption></figcaption></figure>
   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.

         <figure><img src="https://paloaltonetworks.fluidtopics.net/api/khub/maps/aWWAFsfQUhAJF9SNSfCzNw/resources/2DW0qYZQI~nUyJ5IGBYFDw-aWWAFsfQUhAJF9SNSfCzNw/content?v=9f3a2caa80ddc9b4&#x26;Ft-Calling-App=ft/turnkey-portal" alt=""><figcaption></figcaption></figure>

      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.

      <figure><img src="https://paloaltonetworks.fluidtopics.net/api/khub/maps/aWWAFsfQUhAJF9SNSfCzNw/resources/u6s5k0lF5DYBfzaDyyjAdw-aWWAFsfQUhAJF9SNSfCzNw/content?v=47fd9435a26fc24b&#x26;Ft-Calling-App=ft/turnkey-portal" alt=""><figcaption></figcaption></figure>
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 looks 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 3<sup>rd</sup> 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 Cortex XDR, we do not need to change the classifier, as everything that is ingested into Cortex XSOAR 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 → OBJECTS SETUP → Incidents → 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.`**

   <figure><img src="https://paloaltonetworks.fluidtopics.net/api/khub/maps/aWWAFsfQUhAJF9SNSfCzNw/resources/js_meQsTFX5h7ScRVpmVFg-aWWAFsfQUhAJF9SNSfCzNw/content?v=acfc235bb9f2b6c6&#x26;Ft-Calling-App=ft/turnkey-portal" alt=""><figcaption></figcaption></figure>
7. Map one of the system fields.
   1. For the **`OS Version`** field, click Choose data path.
   2. Click **`agent_os_sub_type`**.
   3. Click OK.

      We can see the result is **`Ubuntu 18.04.5 LTS`**.

      <figure><img src="https://paloaltonetworks.fluidtopics.net/api/khub/maps/aWWAFsfQUhAJF9SNSfCzNw/resources/RM7lshvGAmhaqvQxK85PPg-aWWAFsfQUhAJF9SNSfCzNw/content?v=d964327b99fab63d&#x26;Ft-Calling-App=ft/turnkey-portal" alt=""><figcaption></figcaption></figure>
   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, map them.

   <figure><img src="https://paloaltonetworks.fluidtopics.net/api/khub/maps/aWWAFsfQUhAJF9SNSfCzNw/resources/Q8ncuMbaHZaNivYVXfLSkQ-aWWAFsfQUhAJF9SNSfCzNw/content?v=9e2f1caeda911b9e&#x26;Ft-Calling-App=ft/turnkey-portal" alt=""><figcaption></figcaption></figure>
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.

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 Cortex XDR.

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:

   <figure><img src="https://paloaltonetworks.fluidtopics.net/api/khub/maps/aWWAFsfQUhAJF9SNSfCzNw/resources/0rhItaBUw34cjRWXCy3Sxw-aWWAFsfQUhAJF9SNSfCzNw/content?v=5ff6d16cd90b56cd&#x26;Ft-Calling-App=ft/turnkey-portal" alt=""><figcaption></figcaption></figure>
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 a 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
   * Lets 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.

   <figure><img src="https://paloaltonetworks.fluidtopics.net/api/khub/maps/aWWAFsfQUhAJF9SNSfCzNw/resources/TxUGe5SNg5~Pi1_jE03jQg-aWWAFsfQUhAJF9SNSfCzNw/content?v=208df8f2accfd178&#x26;Ft-Calling-App=ft/turnkey-portal" alt=""><figcaption></figcaption></figure>
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.

   <figure><img src="https://paloaltonetworks.fluidtopics.net/api/khub/maps/aWWAFsfQUhAJF9SNSfCzNw/resources/ta~rXkH9bi513BdfgySGUQ-aWWAFsfQUhAJF9SNSfCzNw/content?v=829596cab29d8a81&#x26;Ft-Calling-App=ft/turnkey-portal" alt=""><figcaption></figcaption></figure>
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](/xsoar-6-administrator-guide/6.13/learn-about-cortex-xsoar/customize-and-configure-cortex-xsoar/incidents/post-processing-for-incidents/create-a-post-processing-script.md) to cover as many scenarios as you need.

In this example, when closing an incident, we want to update the owner of the incident automatically 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.

      <figure><img src="https://paloaltonetworks.fluidtopics.net/api/khub/maps/aWWAFsfQUhAJF9SNSfCzNw/resources/eDFxMbfRW24lAb2g_SKbEg-aWWAFsfQUhAJF9SNSfCzNw/content?v=e05a4b0592899153&#x26;Ft-Calling-App=ft/turnkey-portal" alt=""><figcaption></figcaption></figure>
   3. Click Save Version.
2. Add the automation to the Cortex XDR Incident type.

   1. Select Settings → OBJECTS SETUP → Incidents → 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 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 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 customized sections. In the Investigations tab, you see the information that was populated. Change and update as necessary until you have the required information.

<figure><img src="https://paloaltonetworks.fluidtopics.net/api/khub/maps/aWWAFsfQUhAJF9SNSfCzNw/resources/RNyOq7_dJRGeKd~hHNJokA-aWWAFsfQUhAJF9SNSfCzNw/content?v=0abdb7eab34b34f8&#x26;Ft-Calling-App=ft/turnkey-portal" alt=""><figcaption></figcaption></figure>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://cortex-docs.paloaltonetworks.com/tutorials/cortex-xsoar-tutorials/readme/set-up-a-malware-incident-using-the-deployment-wizard.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.