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.
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.
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.
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:
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.
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 to perform certain actions
on incidents as they are ingested into Cortex XSOAR. For example,
drop identical incidents and link to existing incidents.
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:
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.
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.
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.
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
.
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
.
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.
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.
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.
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.
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.
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 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.
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.
Select
Settings
ADVANCED
Incident Types
Phishing
.
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).
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.
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.
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, a link to
a Phishing Campaign incident (if relevant), etc.
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).
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.
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.
Go to
Settings
ADVANCED
Fields
.
Create the boolean fields, such as
Was there
a High Value Target?
Click
New Field
.
In the
Field Type
field, select
Boolean
(checkbox
).
In the
Field Name
field, type the
name you want to use, such as
High Value Target
.
Click
Save
.
Repeat for the other Boolean fields.
Add the
User
field to the phishing type.
Search for
User
.
Click the
User
checkbox and click
Edit
.
In the
Add to Incident Types
field,
select
Phishing
from the dropdown list.
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.
Go to
Settings
ADVANCED
Layouts
.
Select the
Phishing Incident
layout checkbox.
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.
Click the
Phishing Incident
layout.
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.
From the
Library
section,
in the
Sections
tab, drop and drag the
New Section
onto
the
Case info
tab.
Rename the section to
Quick Actions
,
by editing the settings.
In the
Fields and Buttons
tab, drag
and drop the custom buttons we have created and the modified
User
field.
Add existing system fields.
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.
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.
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.
Go to Marketplace and install the following Content Packs
(which contain the required integrations):
The Rasterize integration
is installed out of the box.
Add the integration instances by going to
Settings
INTEGRATIONS
.
Add the
EWS v2
integration instance,
which fetches events, attachments, original emails from an inbox,
searches and deletes emails.
Click
Add instance
.
Click
Fetches incidents
.
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.
Add the email address and password of the designated phishing
inbox for which to fetch incidents.
If there is a specific folder where phishing is stored, type
the relevant folder, otherwise type Inbox.
Click
Has impersonation rights
to
use another user’s email address.
Add any other options as required.
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.
Add the
EWS Mail Sender
integration, which
sends emails to users.
Click
Add instance
.
Add the Exchange URL or Server IP address, Authentication, and
Password. The server version is
2013
and
the authentication type is
Basic (Office 365)
.
Click
Test
and then
Save
& Exit
.
Add the
VirusTotal - Private API
instance,
which investigates suspicious files, domains, URLs, IP addresses, etc.
Click
Add instance
.
Add the
Virus Total - Private API Key
.
Click
Test
and then
Save
& Exit
.
Add the
Palo Alto Networks WildFire v2
instance,
which submits files and returns the report plus looking up the file
reputation.
Click
Add instance
.
Add the Server base URL and API key.
Click
Test
and then
Save
& Exit
.
Add the
Active Directory Query v2
instance,
which accesses and manages Active Directory objects (users, contacts,
and computers) and runs AD queries.
Click
Add instance
.
Add the Server IP address, Port, Credentials, Password,
and Base DN.
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.
Select
Settings
INTEGRATIONS
Classification &
Mapping
EWS - Incoming Mapper
checkbox.
Click
Duplicate
.
Open
EWS - Incoming Mapper_copy
.
In the
Incident Type
field, select
Phishing
.
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.
Click auto-map to automatically map fields based on naming convention.
In this example,
SHA256
maps to
attachmentsSHA256.
Add one of the custom fields we created.
For the
Attachments Included
field,
click
Choose data path
.
In the
Data fetched from EWS
section (right-hand
side of the window), click
has_attachments
.
Click
OK
.
We can see the result is
true
.
When
the incident is ingested, the
Attachments Included
field
shows either
true
or
false
.
Repeat these steps if you have any unmapped custom fields.
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.
Select
Settings
Integrations
Pre-Process Rules
New Rule
.
In the
Rule Name
field, type,
Phishing Email Duplication
.
In the
Conditions for Incoming incident
section,
add the following filter:
In the
Action
field, select
Drop and
update
.
In the
Update
field, add the following rule:
We
are linking the incident to the oldest incident with an identical
Email Subject.
Test the pre-process rule and then select the data from
an incident.
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.
Go to Playbooks and Search for
Phishing Investigation
- Generic v2
.
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.
Review and change the playbook inputs by clicking
Playbook
Triggered
.
Role
: The administrator
is the default role assigned to the incident. We keep this as the
administrator.
SearchAndDelete
: Turn on or
off the Search and Delete Process in EWS or O365. Part of the remediation process.
BlockIndicators
: Also part
of the remediation process.
In this example, we want to manually remediate the incident, so
we keep these as
: 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
.
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.
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.
Update the message (body) by clicking the
Acknowledge
incident was received
task.
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:
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.
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 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.
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).
Review
the investigation stage.
If there are extracted headers, we consider whether the
email should be authenticated. If not, the playbook calculates severity.
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
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.
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.
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.
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).
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.
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.
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.
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.
Create a script in the
Automation
page.
Click
Upload Automation
.
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.
Click
Save Version
.
Add the automation to the
Phishing
incident
type.
Select
Settings
Incident Types
Phishing
Edit
.
In the
Post-process using
field,
select
CloseIncidentbyUserID
.
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.
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.
InvestigationThe 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 thePhishing Campaignincident type (you can also see a link in theLinked Incidentssection in theCase Infotab).
The system starts ingesting incidents from EWS. Every email creates an incident in Cortex XSOAR.
When the incident is ingested, theAttachments Includedfield shows eithertrueorfalse.
We are linking the incident to the oldest incident with an identical Email Subject.
After storing the email address, an email is sent to the user acknowledging that the incident was received.
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 theGet Original Email - EWS/Gmailsub-playbooks (within theGet Original Email - Genericsub-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 headersIf 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.
