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

Cortex XSOAR Tutorials 6.x

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

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.

Note

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.

Stage

Section

Description

1.

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.

2.

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:

3

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.

4.

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.

5.

Add Pre-Process Rules

Add pre-process rules to perform certain actions on incidents as they are ingested into Cortex XSOAR. For example, drop identical incidents and link to existing incidents.

6.

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.

7.

Create Post-Process Rules

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

8.

Investigation

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:

Integration

Description

EWS v2

Messaging

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-incidentype.png
  • 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.

phishing-campaign.png

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.

      phishing-incidentype2.png
  4. In the Indicators Extraction Rules tab, review and change the fields that are being extracted, if required.

    phishing-extract.png

    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.

    phishing-case.png

    Investigation

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

    phishing-linked.png
  • 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

Comments/Values

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.

User

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.

      phishing-fields.png
  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.

    phishing-newfm.png
  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

    Integration

    EWS

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

    phishing-ews.png

    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.

      phishing-ewsend.png
  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.

    phishing-map.png
  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.

      phishing-attach.png

      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:

    phishing-preprop.png
  4. In the Action field, select Drop and update.

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

    phishing-update.png

    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.

    phishing-test.png
  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.

    Note

    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.

    phishing-pb-enage-8-x.png

    After storing the email address, an email is sent to the user acknowledging that the incident was received.

    1. Update the message (body) by clicking the Acknowledge incident was received task.

      phishing-pb-task.png
  5. Review the Triage stage.

    The triage section extracts relevant information, including indicators from a file, detonates the file, and if there is a training model uses machine learning to predict the phishing type and update the incident with predictions. Triage includes the following tasks:

    phishing-pb-triage.png
    1. Process Email - Generic Playbook

      Triage starts with the Process Email - Generic playbook, which processes the email and extracts relevant information from files including attachments. This playbook branches according to whether the email is attached.

      Email attached

      If the original email is attached, email artifacts and attachments are extracted (Extract email artifacts and attachments task, which uses the ParseEmailFiles script). This task takes the email file and extracts all email addresses, subject, executable files, attachments, etc. The task does not finish until everything has been extracted (inline). The results are then entered into the incident layout.

      phishing-pb-extract.png

      Forwarded email (no attachment)

      If the email was not attached, and the original email is not necessary (the forwarded email contains sufficient information for an investigation), the details are added to the incident.

      If the original email is necessary for the investigation, the playbook uses the Get Original Email - EWS/Gmail sub-playbooks (within the Get Original Email - Generic sub-playbook) to obtain the original email and then adds details to the incident, such as sender, text body, size, body, etc. As we are using EWS we do not need to update this task.

      This flow depends on the playbook input (whether the original email is attached or forwarded). It can be useful if someone forwarded an email instead of attaching the email as a file. Nevertheless, attaching a file is still best practice.

      phishing-pb-attach.png

      Email headers

      If email headers were extracted, the headers are displayed (you can later use them for authentication). At the same time attachment information is added, such as size, MD5 hashes, number of attachments, etc.

      If the email is HTML-formatted (not in all cases), it creates an image out of that HTML data to show how the email was seen by the user using Rasterize.

    2. After extracting the relevant information, the following tasks are undertaken at the same time:

      • Detonate a file using the Denote File - Generic sub-playbook

        Any sandbox integrations that you have enabled will run and provide details about the file reputation, whether the email is forwarded or attached as a file. If, for example, the email is forwarded (not attached as a file), if the email contains a PDF file, then that PDF file will go through detonation / indicator extraction. In this example we use Palo Alto Networks WildFire to detonate files. The payload is triggered so files can be isolated and analyzed.

        Note

        Detonation is different from file enrichment. File enrichment such as Virus Total provides more information about the file, whether it is malicious, whether it belongs to a particular botnet, etc. The file is not detonated.

        If your sandbox integration is not here, you need to add it.

        phishing-pb-sandbox.png
      • Extract indicators from a file using Extract Indicators from File - Generic v2 playbook

        If a file is attached, you can extract more indicators from the file. Indicators may exist in the file and not the email. You can extract text based files, Word, PDF, or other supported files, like PPT files (sometimes these contain executable macros). For PDFs, we utilize the image OCR, which extracts text from images inside PDF files.

        phishing-pb-ind.png
      • Machine learning

        If you have set up a machine learning model, in the Predict phishing type using a pre-trained phishing model task, enter the modelName and any other parameters you require. This result will form part of the DBot indicator score when calculating the severity.

        As this is the first time we are setting up incidents, we do not have sufficient information for machine learning, but once we start ingesting incidents we can add a phishing training model.

  6. 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. The Entity Enrichment - Phishing v2 uses 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.

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

    • 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, and checks for domain squatting (such as using a similar domain).

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

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

    As we are using VirusTotal Private API, 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).

  7. Review the investigation stage.

    If there are extracted headers, we consider whether the email should be authenticated. If not, the playbook calculates severity.

    phishing-pb-investigation.png
    1. Authenticate the email.

      Using DKIM, DMARC and SPF we check to see if the email is coming from its supported source, or whether the email has been tampered with.

      The result of the authenticity check is added to the incident field using the setIncident script.

      At the beginning of the playbook (Playbook Triggered), in the Inputs section, we set the email authenticity check to true.

    2. Email Campaign Search

      The Detect & Manage Phishing Campaigns sub-playbook uses the FindEmailCampaign automation, which utilizes machine-learning to identify existing incidents in Cortex XSOAR that are part of the same campaign of the currently investigated incident. You can customize the inputs as required.

      If the sub-playbook finds that the incident is part of a campaign, it generates campaign-related data which you can observe in the linked Phishing Campaign incident, and take actions related to the campaign.

      You need to install the Phishing Campaign Content Pack, which includes the Detect & Manage Phishing Campaigns sub-playbook.

    3. Microsoft Headers Check

      The Process Microsoft’s Anti-Spam Headers playbook finds the SCL, BCL and PCL values (if they exist) in the Microsoft headers, calculates the severity based on those scores and classifies whether the email is spam. You can change the minimum severity of each score.

    4. Calculate the severity by using the 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:

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

      • 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. If one critical entity is involved in the incident, it will raise the severity to critical.

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

      • The DBot Score from tasks that run in this playbook, (like Process Email, extract indicators from file, detonation playbooks, machine learning, etc.)

      • The Microsoft Headers Severity (if a value is returned).

      The incident severity is determined by the highest returned score.

      phishing-pb-sev.png
    5. Assign to analyst

      In the Assign to analyst task we can assign the incident according to a role, and set an assignment to make it random, who is online, who is less busy, etc. In this example, we will assign according to the least busy user (less-busy-user).

      phishing-assign.png
    6. Whether the Email is Malicious

      Upon looking at the incident severity, we check to see if the email is malicious. If the severity is equal or greater than 2 (both high and critical) it is considered malicious. We can change this if necessary.

  8. Undetermined/Malicious email

    This stage of the process depends on whether the email is undetermined or malicious.

    • Undetermined

      This is a manual task. If the severity is low or unknown it is regarded as undetermined. The analyst manually reviews the incident and decides whether it is malicious. If not, the analyst updates the user (who sent the email) that the email is safe and then closes the investigation.

    • Malicious email

      If malicious, we update the user that the email is malicious and then start the remediation process. If the incident was part of a phishing campaign we also update the user that the email is part of a malicious campaign.

  9. Review the Remediation Process

    The last part of the process is remediation.

    Start with a time to see how long it takes to remediate. There are 3 options:

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

    • Use the Search and Delete Emails Generic v2 sub-playbook: Searches and deletes the email from all users across the organization. We use EWS to search and delete these emails. If you want to change to O365, in the Playbook Triggered section, type O365 in the SearchAndDeleteIntegration field.

    • Manually remediate the incident.

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

    After we have finished the remediation section, the timer stops and the investigation 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 Processing script to cover as many scenarios as you need.Post Processing for Incidents

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

  1. Create a script in the Automation page.

    1. Click Upload Automation.

    2. Upload the following script.

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

      Ensure that the post-processing tag is selected.

      phishing-process.png
    3. Click Save Version.

  2. Add the automation to the Phishing incident type.

    1. Select SettingsOBJECTS SETUPIncidentsTypesPhishingEdit.

    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

Go to Incidents and select a phishing incident. In the Case info tab you can see both the out of the box and the customized sections. In the Investigations tab, you see the information that was populated.

phishing-invest.png

You are now ready for analysts to start investigating phishing incidents.