Setting Up a Phishing Incident in Cortex XSOAR

A tutorial that takes you through a phishing incident from the initial planning stage to investigating an incident
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.
To get up and running with a phishing incident in Cortex XSOAR, follow these stages.
Stage
Section
Description
1.
Before installing Cortex XSOAR, you should start planning how are you going to ingest incidents into Cortex XSOAR, what does an analyst need to investigate, how to deal with the response, what integrations you need, etc.
2.
Cortex XSOAR comes out of the box with the Phishing Content Pack, which includes the Phishing incident type. In this section, we need to the following:
3
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.
Classification enables you to have a better control of the type and structure of incoming incidents. Map the fields so you can see these fields in the incident layout.
5.
Add pre-process rules to perform certain actions on incidents as they are ingested into Cortex XSOAR. For example, drop identical incidents and link to existing incidents.
6.
Playbooks are triggered either when an incident is created or when you run them manually as part of an investigation. In this example, we use the
Phishing Investigation - Generic V2
playbook.
7.
Once the incident is complete and you are ready to close it, you can run various post-processing actions on the incident.
8.
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 are 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.
  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.
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
Virus Total - Private API
Data enrichment and threat intelligence
Active Directory Query v2
Palo Alto Networks WildFire V2
Forensic and Malware analysis
Rasterize
Utilities
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.
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 can chose 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.
  1. Select
    Settings
    ADVANCED
    Incident Types
    Phishing
    .
  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 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
Settings
ADVANCED
Layouts
Phishing 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, linked incidents, etc.
    Investigation
    The investigation tab contains an overview of the relevant information an analyst may require about the phishing investigation such as email basic information (sender, subject, to, ID, etc.), the email text, headers, HTML image, attachments, indicators, etc.
  • 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.
  • Email Campaign
    If the phishing incident is part of a bigger phishing campaign, the Email Campaign tab shows key information about the campaign, such as the incidents involved, the recipients, the senders, the email body, etc. Also a dynamic-section allows you to take action directly from the layout, such as informing the recipients about the campaign, or linking, unlinking, closing and reopening the related incidents.
For more information about customizing incident types generally, see Incident Investigation.

Create Custom Fields for the Phishing Layout

As we have now familiar with the layout, we 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
    Settings
    ADVANCED
    Fields
    .
  2. Create the boolean fields, such as 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
    Settings
    ADVANCED
    Layouts
    .
  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.
  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
    Integration
    EWS
    EWS Mail Sender
    Virus Total - Private API
    Palo Alto Networks WildFire
    Active Directory Query
    The Rasterize integration is installed out of the box.
  2. Add the integration instances by going to
    Settings
    INTEGRATIONS
    .
  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. Add the email address and password of the designated phishing inbox for which to fetch incidents.
    4. If there is a specific folder where phishing is stored, type the relevant folder, otherwise type Inbox.
    5. Click
      Impersonation rights
      to use another user’s email address.
    6. Add any other options as required.
    7. 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 it manually.
    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
      .
  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 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
    Settings
    INTEGRATIONS
    Classification & Mapping
    EWS - 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
      Chose data path
      .
    2. 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 for the original sender field and any other fields that require mapping.
    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.
  1. Select
    Settings
    Integrations
    Pre-Process Rules
    New Rule
    .
  2. In the
    Rule Name
    field, type,
    Phishing Email Duplication
    .
  3. In the
    Conditions for Incoming incident
    section, add the following:
  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
      : Part of the remediation process.
    3. BlockIndicators
      : Also part of the 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
      .
    6. 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.
    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.
  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:
    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.
      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.
      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.
        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.
      • 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.
      • Machine learning
        If you have set up a machine learning model, in the Predict phishing type using 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. 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
      .
    • 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.
    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. Find email campaigns
      The
      FindEmailCampaign
      script utilizes machine-learning to identify existing incidents in Cortex XSOAR that are part of the same campaign of the currently investigated incident. If you want to use that script, you have to set the
      SearchEmailCampaigns
      playbook input to
      true
      . You can customize the arguments of the script to suit the identification to the way you use the playbook.
      When the script is used, if it finds that the incident is part of a campaign, it generates campaign-related data which you can observe in the
      Email Campaign
      tab in the incident layout, and take actions related to the campaign.
    3. Calculate Severity 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 incident severity is determined by the highest returned score.
    4. 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).
    5. 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.
  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
      Execute the Block Indicators
      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
      Execute the Search and Delete
      sub-playbook: Searches and deletes the email from all users across the organization. We use EWS to search and delete these emails.
    • 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
    Manually remediate the incident
    .
    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.
In this example, when closing an incident we want to update automatically the owner of the incident to the user who closes it. This user is responsible for any post closure issues.
  1. Create a script in the
    Automation
    page.
    1. Click
      Upload Automation
      .
    2. Upload the following script.
      commonfields: id: Close Incident by User ID version: 1 contentitemexportablefields: contentitemfields: packID: "" itemVersion: "" fromServerVersion: "" toServerVersion: "" propagationLabels: - all vcShouldKeepItemLegacyProdMachine: false name: CloseIncidentbyUserID script: |- result = (demisto.args()) demisto.executeCommand("setIncident", {'owner': result['closingUserId']}) type: python tags: - post-processing enabled: true scripttarget: 0 subtype: python2 pswd: "" runonce: false runas: DBotWeakRole
      Ensure that the
      post-processing
      tag is selected.
    3. Click
      Save Version
      .
  2. Add the automation to the
    Phishing
    incident type.
    1. Select
      Settings
      Incident Types
      Phishing
      Edit
      .
    2. In the
      Post-process using
      field, select
      CloseIncidentbyUserID
      .
    3. Click
      Save
      .
    When a user closes an incident, the user who closed the incident now becomes the owner. When an incident is re-opened. the user who closed the incident will be able to keep track of reopened incidents.

Investigation

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.
You are now ready for analysts to start investigating phishing incidents.

Recommended For You