Set up a Phishing Incident in Cortex XSOAR - Tutorials - 6.x - Cortex XSOAR - Cortex - Security Operations

Cortex XSOAR Tutorials 6.x

Cortex XSOAR
Creation date
Last date published

Phishing is the fraudulent attempt to obtain sensitive information, such as user names, passwords and credit card details by disguising an entity as trustworthy in an electronic communication. It is usually carried out by email spoofing or instant messaging, and often directs users to enter personal information at a fake website which matches the look and feel of a legitimate site.

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.

This tutorial takes you through the process of setting up a phishing incident in Cortex XSOAR. Use this template as a base resource to design and implement your own automated response to a phishing incident.


You can also manage phishing alert incidents generated from email security gateways using the PhishingAlerts content pack.

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





Plan Your Phishing Incident

Before installing Cortex XSOAR, you should start planning how you are going to ingest incidents into Cortex XSOAR, what an analysts need to investigate, how to deal with the response, what integrations you need, etc.


Phishing Incident Type Customization

Cortex XSOAR comes out of the box with the Phishing Content Pack, which includes the Phishing incident type. In this section, we need to do the following:


Configure Third-Party Integrations

After installing Content Packs from the Marketplace, add your required instances. In this example, we are going to add the EWS Content Pack, which includes the EWS integration to ingest incidents, the VirusTotal Content Pack for the VirusTotal integration for data enrichment, etc.


Classify and Map EWS 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.


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.


Review and Customize Phishing Playbooks

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 Phishing Investigation - Generic V2 playbook.


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.



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

Plan Your Phishing Incident

Before you begin, consider the following requirements:

  1. Where do your phishing incidents originate?

    Sometimes, phishing incidents originate from another phishing tool, like PhishLabs, or from an inbox in Gmail, Microsoft O365, EWS, etc. You should consider whether you want to use impersonation rights if you need to retrieve the phishing email from the user’s email. If you do not have the original email, investigation is more problematic.

    In this example, all emails are either forwarded or attached as a file to an email, which is sent to an organization's designated phishing email inbox using Microsoft EWS. We want to fetch all phishing emails, whether they are forwarded or attached into Cortex XSOAR, using Microsoft EWS. We want to use impersonation rights to get the original email from a user’s inbox. Although not essential, we want to use Active Directory to obtain users’ details.

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

    You probably want to see the source address, destination address, source email, destination email, email headers, body, email HTML, email text, hash, extension, etc.

    The phishing incident layout comes out of the box with the fields that are necessary to investigate a phishing incident. These sections and fields are fully customizable.

  3. What Incident response process do you currently use?

    You may want to check IP addresses for location, act according to the country to increase severity, block IPs, manually investigate further, close incidents, etc. We can add these steps into a playbook.

    You can use and customize out of the box playbooks, or create your own playbook for a phishing investigation and response.

  4. Which enrichment feeds do you use?

    Usually, you want to extract email headers from the original email, subject, body, and extract relevant IOCs, etc. In this example, we enrich all extracted IOCs via VirusTotal Private API.

  5. Which 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 email. You can run this automatically in the playbook or use it manually through a detonation integration. In this example, we detonate malicious files using Palo Alto Networks Wildfire.

  6. Are there any manual steps that need to be taken?

    Consider which manual steps need to be taken. These steps can be added to a playbook.

    For example, consider the following:

    • At what stage do you want an analyst to investigate?

    • Whether you want to confirm before an email is deleted from another user’s account.

    • Investigate if there is an unexpected error.

    In this example, we want the analyst to investigate to see if the incident was malicious after indicators were extracted from the email and a file attachment was detonated.

  7. Are there end-user interactive steps?

    Do you need to ask the end user questions via email, Slack or any other communication channels (we can also ask questions via the playbook)? Do you need management approval by email? Do you need to get another analyst? These steps can be added to a playbook such as error checking, escalation, etc.

  8. Is there any duplication?

    In a phishing campaign many emails are sent which contain similar text. You may want to find active incidents with a similar subject line and sender, close duplicate incidents, etc.

    In Cortex XSOAR, this can be undertaken through a script (pre-process script), through a playbook, an automation, or manually using the CLI. For example, if you want to manually query duplicate incidents, use the FindSimilarIncidents command.Automatic De-Duplication Using Scripts

  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?

    In this example, when closing an incident we want to update automatically the owner of the incident, so if it is reopened this user receives notification.

  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.

    In this example, we want an option for read-only access for certain roles.

  11. Do you want to find and manage Phishing Campaign incidents?

    A phishing campaign is a collection of phishing incidents that originate from the same attacker, or as part of the same organized attack launched against multiple users.

Summary of Third-Party integrations

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



EWS v2


EWS Mail Sender

Mail sender

VirusTotal - Private API

Data enrichment and threat intelligence

Active Directory Query v2

Palo Alto Networks WildFire V2

Forensic and Malware analysis

All these integrations are freely available in Cortex XSOAR and the Content Packs can be installed from the Marketplace.

As you have finished the planning stage, now set up phishing incidents in Cortex XSOAR.

Phishing Incident Type Customization

Cortex XSOAR comes out of the box with the Phishing Content Pack (go to Marketplace and search for Phishing), which contains the following:

  • Phishing incident type: Contains a unique set of data that is relevant to phishing. When a phishing incident is ingested into Cortex XSOAR, by default, it uses the phishing incident type. You can set which phishing playbook to run, which layout, add a post process script, define indicator extraction rules, etc.

  • Phishing layout: Displays relevant data for analysts to investigate a phishing incident from ingestion to remediation. For example, in the Investigation tab, you can see information about the email (ID, subject, sender, etc.), the email text, attachments, the email image (using Rasterize), indicators, etc.

  • Phishing incident fields: Contains fields which assist with the phishing investigation, such as attachment type, size, email body, email headers, reporter email address, etc., which are added to the layout.

  • Phishing playbooks and sub-playbooks: Automates the phishing investigation and alert response. For example, Phishing Investigation - Generic v2, Process Email - Generic, Get Original Email - EWS, etc.

  • Phishing automations: Automations that check for email authenticity, set severity, etc. Run these in a playbook or in the CLI.

Phishing Campaigns

In the future, we want to detect whether a phishing incident will be part of a phishing campaign. Install the Phishing Campaign Content Pack to find, create, and manage phishing campaigns. When phishing incidents are similar to each other, Cortex XSOAR detects and creates the links between them, and adds them to a Phishing Campaign incident. This enables you to view and take action as a whole (such as informing the recipients about the campaign, or linking, unlinking, closing and reopening the related incidents), rather than spend time investigating each incident separately.


In this section, we need to do the following:

Customize the Phishing Incident Type

A phishing incident is ingested into Cortex XSOAR and is classified as such through classification. Classification enables you to select which incident type to create. In this case it is the phishing 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.Indicator Extraction

  1. Select SettingsOBJECTS SETUPIncidentsTypesPhishing.

  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 Phishing Investigation - Generic v2 playbook.

      We want to change the default playbook from Phishing Playbook Manual to Phishing Investigation - Generic v2 playbook, as it is a comprehensive playbook covering triage to remediation.

    • In the Layout field, we will keep the Phishing 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 Rules tab, review and change the fields that are being extracted, if required.


    You can see the relevant fields that are being extracted for phishing (Email Body, Email Reply To, Email Body HTML, etc.) We want to extract Email Subject, attachment hashes, Email body, etc. As these are designed for phishing types we want to keep these out of the box settings. We can always update these later.

  5. Click Save.

Review the Phishing 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 email 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 phishing layout, before you make any changes. You may want to create sections, add buttons, add custom fields, etc. To view the layout, select SettingsOBJECTS SETUPIncidentsLayoutsPhishing Incident.

You can see the following tabs:

  • Incident Summary

    In the Incident Summary tab, there are seven out of the box tabs. 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 phishing incident (such as type, severity, playbook, etc.), timeline information (when the incident occurred, created, updated, etc.), Work Plan information (such as outstanding tasks), team members, a link to a Phishing Campaign incident (if relevant), etc.



    The investigation tab contains an overview of the relevant information an analyst may require about the phishing investigation such as general email information (sender, subject, to, ID, etc.), the email text, headers, HTML image, attachments, indicators, etc.

    If the phishing incident is part of a phishing campaign, the incident is linked to the Phishing Campaign incident type (you can also see a link in the Linked Incidents section in the Case Info tab).

  • New/Edit Form

    Contains information relevant to creating or editing a phishing incident.

  • Close Form

    Contains information relevant to closing a phishing incident.

  • Incident quick view

    Contains summary information relating to the phishing incident.

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

Create Custom Fields for the Phishing Layout

As you are now familiar with the layout, you need to create custom fields. These fields can then be added to the phishing 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


Was an anonymous Email Service Used?

Boolean (checkbox)

Actors using anonymous emails. We will add this to the Case info tab and when creating or editing an incident.

Was a link clicked?

Boolean (checkbox)

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

Was there a High Value Target?

Boolean (checkbox)

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

Attachment Included?

Boolean (Checkbox)

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


This is currently used in Malware (called User), but we want to add this to phishing. These are the user details from AD.

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

  1. Go to SettingsOBJECTS SETUPIncidentsIncident Fields.

  2. Create the Boolean fields, such as Was there a High Value Target?

    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 High Value Target.

    4. Click Save.

    5. Repeat for the other Boolean fields.

  3. Add the User field to the phishing type.

    1. Search for User.

    2. Click the User checkbox and click Edit.

    3. In the Add to Incident Types field, select Phishing from the dropdown list.

    4. Click Save.

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

Customize the Phishing Incident Layout

We are going to add both custom fields and existing out of the box fields to the phishing layout.

  1. Go to SettingsOBJECTS SETUPIncidentsLayouts.

  2. Select the Phishing 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 Phishing Incident layout.

  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 and the modified User field.

  6. Add existing system fields.

    1. In the Case Details section, drag and drop the XSOAR Read Only Roles field.

      In the planning stage, we identified the need to add a read only button for a phishing incident. This allows analysts to restrict access to the incident to read-only.

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

  8. Click Save Version.

    This enables you to restore any changes made.

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



    EWS v2

    EWS Mail Sender

    EWS Mail Sender

    Virus Total - Private API

    Virus Total - Private API

    Palo Alto Networks WildFire

    Palo Alto Networks WildFire v2

    The Rasterize integration is installed out of the box.

  2. Add the integration instances by going to SettingsINTEGRATIONS.

  3. Add the EWS v2 integration instance, which fetches events, attachments, original emails from an inbox, searches and deletes emails.

    1. Click Add instance.

    2. Click Fetches incidents.

    3. In the Incident type (if classifier doesn’t exist) select Phishing.

      As this is a dedicated phishing inbox, all incidents will be Phishing. You do not need a classifier.

    4. Add the email address and password of the designated phishing inbox for which to fetch incidents.

    5. If there is a specific folder where phishing is stored, type the relevant folder, otherwise type Inbox.

    6. Click Has impersonation rights to use another user’s email address.

    7. Add any other options as required.

    8. Click Test and then Save & Exit.

    After adding your email and password, Cortex XSOAR attempts automatically to connect to EWS. If you receive an error message that auto discovery failed, you need to add details manually (the exchange server hostname, the domain username, the exchange server version, and the Advanced Mode Override Authentication type).


    The system starts ingesting incidents from EWS. Every email creates an incident in Cortex XSOAR.

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

  5. Add the VirusTotal - Private API instance, which investigates suspicious files, domains, URLs, IP addresses, etc.

    1. Click Add instance.

    2. Add the Virus Total - Private 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.

Classify and Map EWS Fields

Classification determines the type of incident that is created for events ingested from a specific integration (EWS). Mapping matches the fields from your third-party integration to the fields that you associate with the phishing incident (very likely displayed in the layout as well).

EWS comes out of the box with the following:

  • EWS - Classifier

  • EWS - Incoming Mapper

As we are ingesting incidents from a phishing mailbox, we do not need to change the classifier, as everything that is ingested into Cortex XSOAR from the EWS mailbox is classified as phishing. 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

Although incidents are ingested into Cortex XSOAR as phishing, we need to ensure the correct attributes are mapped to the phishing incident fields in the layout.

Most of the mapping is done out of the box. Nevertheless, it's important to review the data, check that it's mapped correctly and add fields where necessary.

  1. Select SettingsOBJECTS SETUPIncidentsClassification & MappingEWS - Incoming Mapper checkbox.

  2. Click Duplicate.

  3. Open EWS - Incoming Mapper_copy.

  4. In the Incident Type field, select Phishing.

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

    On the left side of the screen you see all of the fields that are available for the phishing incident type. We can see that some fields are already mapped, such as Attachment Count, Attachment ID, Email Body, Email CC, etc.

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

  7. Add one of the custom fields we created.

    1. For the Attachments Included field, click Choose data path.

    2. In the Data fetched from EWS section (right-hand side of the window), click has_attachments.

    3. Click OK.

      We can see the result is true.


      When the incident is ingested, the Attachments Included field shows either true or false.

    4. Repeat these steps if you have any unmapped custom fields.

    5. Go back to the EWS instance settings and change the mapper to EWS - Incoming Mapper_copy.

Add Pre-Process Rules

Although we have just started ingesting incidents into Cortex XSOAR, you may get a number of phishing incidents that are identical, particularly in phishing campaigns. 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. In this example, we have a number of emails that contain Phishing. We want to drop incidents that are very similar and show only one incident, linked to the dropped incidents.Create Pre-Process Rules for Incidents

  1. Select SettingsIntegrationsPre-Process RulesNew Rule.

  2. In the Rule Name field, type, Phishing Email Duplication.

  3. In the Conditions for Incoming incident section, add the following filter:

  4. In the Action field, select Drop and update.

  5. In the Update field, add the following rule:


    We are linking the incident to the oldest incident with an identical Email Subject.

  6. Test the pre-process rule and then select the data from an incident.

  7. Click Save.

    All future incidents are dropped and linked to the oldest open incident.

Review and Customize Phishing Playbooks

For any phishing threat or attack, a SOC team needs to go through the following processes sequentially:

  • Detection

  • Identification

  • Analysis

  • Remediation

Each of the high-level processes might contain a number of sub-process that require step-by-step actions to be performed using various tools. You can use playbooks, which map to each other to create a long chained connection of playbooks to detect, identify, analyze and remediate an event.

The Phishing Content Pack comes out of the box with a number of playbooks, such as the Phishing Investigation - Generic v2, Process Email - Generic, Calculate Severity By Email Authenticity, etc. You can customize these out of the box playbooks, or create your own playbook.

Customize the Phishing Investigation - Generic v2 Playbook

In this example, select the Phishing Investigation - Generic v2, 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 Phishing Investigation - Generic v2.

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


    If you want to receive content updates for the playbook, duplicate rather than detach the playbook.

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

    1. Role: The administrator is the default role assigned to the incident. We keep this as the administrator.

    2. SearchAndDelete: Turn on or off the Search and Delete Process in EWS or O365. Part of remediation process.

    3. BlockIndicators: Also part of remediation process. In this example, we want to manually remediate the incident, so we keep these as false.

    4. AuthenticationEmail: Whether to authenticate the email. Default is false. We change this to true. See Authenticate the email under the investigation stage.

    5. OnCall: Whether to assign a user that is currently on shift. To define shifts, see Shift Management. We change this to true.Shift Management

    6. Search and Delete Integration: By default this is set to EWS. Change this if you are using O365.

      Although we are using EWS, if you use O365 continue with the O365 inputs.

      If you are changing the input to O365 ensure that you change the input in the Search and Delete Emails - Generic v2 sub-playbook referred to in step 9.

    7. CheckMicrosoftHeaders: If using EWS or O365, the Bulk Confidence Level (BCL), Spam Confidence Level (SCL) and the Phishing Confidence Level (PCL) values on the Microsoft headers will be considered as part of severity and email classification (whether the email is spam). These values help security teams determine whether the email is coming from a spam, phishing or bulk sender. Default is true.

    8. Click Save.

      After the playbook starts, the detection timer begins, which detects how long it takes to detect the incident. You can change which timer to start but we will use the default.

  4. Review the Engage with User stage.

    The playbook does 2 tasks simultaneously:

    • Engages with the user

    • Triage

    The Engage with User stage stores the email address of the user. If the reporter email address was not present, the Email Address Enrichment - Generic v2.1 sub-playbook finds the email address of the user. In the task for this sub-playbook, you can enter an internal domain if necessary.