In this example, select the Phishing - Generic v3, 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 - Generic v3.
To edit the playbook (add/delete tasks, sub-playbooks, or the flow, etc.) choose Detach Playbook from the three button menu.
Note
If you want to receive content updates for the playbook, duplicate rather than detach the playbook. If you duplicate the playbook, change the default playbook for the Phishing incident type from Phishing - Generic v3 to your new playbook name.
Review and change the playbook inputs by clicking Playbook Triggered.
Role: By default, the least busy user is assigned to the incident. If you set a role, the incident will only be assigned to users with that role.
SearchAndDelete: Turn on or off the Search and Delete Process in EWS O365. Part of the remediation process. If set to true, in case of a malicious email, the Search and Delete sub-playbook looks for other instances of the email and deletes them pending analyst approval. We will leave the default option,
False.BlockIndicators: Also part of the remediation process. Automatically blocks malicious indicators in relevant integrations. For our example, we keep this as
False.AuthenticationEmail: Whether to authenticate the email. Leave as the default,
true. See Authenticate the email under the investigation stage.OnCall: Whether to assign a user that is currently on shift. To define shifts, see Shift Management. Change this to
True.SearchAndDeleteIntegration: This setting is only relevant if SearchAndDelete is set to
true. If you later decide to use the SearchAndDelete option, change the integration here fromEWStoO365.If you use enable SearchAndDelete and set the SearchAndDeleteIntegration to O365, continue with the O365 inputs such as O365DeleteType.
CheckMicrosoftHeaders: If using EWS O365, the Bulk Confidence Level (BCL), Spam Confidence Level (SCL) and the Phishing Confidence Level (PCL) values on the Microsoft headers are 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. Leave as the default,
True.InternalDomains: When the Email Address Enrichment Generic v2.1 sub-playbook runs, it uses the internal domain entered here to determine if the email was reported from an internal or external email address.
GetOriginalEmail: Used to retrieve the original email, when the phishing email is forwarded and not attached. Change this to
Trueonly if you have permissions in EWS O365 to execute global search (eDiscovery). This input is used to determine if the Get Original Email - Generic v2 sub-playbook should run.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 of the playbook.
The playbook does 2 tasks simultaneously:
Engages with the user
Triage
The Engage with User stage stores the name of the user. The Email Address Enrichment - Generic v2.1 sub-playbook here receives the email address of the user reporting the phishing email. If there is an email address from an internal domain, the sub-playbook uses Active Directory to find the name of the user reporting the phishing email. When we engage with the user, we can then address them by name.
An email is sent to the reporting user acknowledging that the incident was received. You can update the message (body) by clicking the Acknowledge incident was received task.
Triage section of the playbook.
The triage section extracts relevant information such as indicators from a file, detonates the file, and uses machine learning to predict the phishing type and update the incident with predictions. Triage includes the following tasks:
Process Email - Generic v2
Triage starts with the Process Email - Generic v2 playbook, which processes the email and extracts relevant information from files including attachments. This playbook branches according to whether the email is attached. To view the playbook, hover over the task and then click the eye icon below the task.
Extract email artifacts and attachments task
Email artifacts and attachments are extracted by this task, which uses the
ParseEmailFilesV2script. This task takes the email file and extracts all email addresses, subject, file attachments, etc. The task does not finish until everything has been extracted (inline). The results are then entered into the incident layout.Get Original Email - Generic v2 sub-playbook
While best practice is to attach a file containing the email when reporting spam or phishing, in some cases, users will forward the email instead.
If the original email is necessary for the investigation and not attached and the GetOriginalEmail input in the main playbook is set to
True, the Get Original - Generic v2 sub-playbook obtains the original email and then adds details to the incident, such as sender, text body, size, body, etc.Headers section
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.
Email Screenshot section
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, we return to the Phishing - Generic v3 main playbook. The following tasks are undertaken at the same time:
Detonate File - Generic sub-playbook
Files are executed in an isolated sandbox environment and their behavior is analyzed. Any sandbox integrations that you have enabled 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. For example, VirusTotal file enrichment provides reputation information about the file, based on the file hash. If VirusTotal does not recognize the file hash, no enrichment information is returned, unless the actual file is submitted for analysis. A sandbox integration, by contrast, runs the file in an isolated environment and provides exact information about the file execution.
If your sandbox integration is not here, you can add it.
Detonate URL sub-playbook
This sub-playbook uses integrations to safely detonate URLs in a sandbox environment and analyze the website behavior.
Extract Indicators from File - Generic v2 sub-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 - Machine Learning Analysis sub-playbook
The Phishing - Machine Learning Analysis sub-playbook performs two functions.
Predict Phishing Type - The playbook uses your custom trained phishing model to predict the phishing type. If you do not have a custom trained phishing model, it uses a pre-trained out-of-the-box phishing model instead. If the model is able to predict the phishing type, the incident is updated with the prediction.
Predict Phishing URLs - If the Rasterize integration is enabled, the DBotPredictURLPhishing script predicts phishing URLs.
Indicator Enrichment
After extracting indicators from an email 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 playbook contains the following sub-playbooks:
File Enrichment - Generic v2: Enriches the file using the File Enrichment - VirusTotal (API v3) playbook. If there is a SHA256 hash and Cylance Protect v2 is enabled, it 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 the !IP command, VirusTotal automation (if enabled) and Threat Crowd (if enabled).
Email Address Enrichment - Generic v2.1: Checks whether email addresses are internal or external. For internal email addresses, additional information is retrieved using Active Directory. For external email addresses, this sub-playbook checks for a domain list input and for domain squatting (such as using a similar domain).
URL Enrichment - Generic v2: Checks for URLs, verifies SSL & captures screenshots using the Rasterize integration.
Domain Enrichment - Generic v2: Enriches domain using Cisco Umbrella (if enabled), and VirusTotal (if enabled).
As we are using VirusTotal, 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).
Investigation
Microsoft's Headers Check
At the beginning of the playbook (Playbook Triggered), in the Inputs section, we left CheckMicrosoftHeaders as the default,
True.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 or phishing. You can change the minimum severity of each score.
Email Campaign Search
The Detect & Manage Phishing Campaigns sub-playbook uses the
FindEmailCampaignautomation, 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.
Email Authenticity Check
At the beginning of the playbook (Playbook Triggered), in the Inputs section, we left AuthenticateEmail as the default,
True.Using DKIM, DMARC and SPF we check to see if the email is coming from its alleged source, or whether the email has been tampered with.
The result of the authenticity check is added to the incident field using the
setIncidentscript.Domain-squatting
If domain-squatting occurred, the result is saved to the incident field.
Email Indicators Hunting
At the beginning of the playbook (Playbook Triggered), in the Inputs section, we left HuntEmailIndicators as the default,
True.The Phishing - Indicators Hunting sub-playbook runs to hunt malicious indicators found in other emails and optionally, automatically create new incidents for each found email if EmailHuntingCreateNewIncidents is set to
True.
The results of the previous tasks are used by the Calculate Severity - Generic v2 sub-playbook, which calculates and assigns the incident severity based on the highest returned severity level from the following:
Authenticity of the email (whether it passed the authenticity check).
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 the parent playbook or sub-playbooks, (such as 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.
The incident is now assigned to an analyst. Incidents can be assigned according to a role such as Analyst, by the least busy user (less-busy-user), randomly, by user online, etc. For this task, by default, the incident is assigned to the least busy user.
The final task in the investigation section determines Is the email malicious?.
The incident severity determines if the email is malicious. If the severity is equal or greater than 2 (medium is 2, high is 3, critical is 4), it is considered malicious. We can change this criteria if necessary.
Undetermined/Email is Malicious
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.
Remediation
The last part of the process is remediation.
A timer starts at this point to track remediation time.
The Search and Delete Emails Generic v2 sub-playbook searches and deletes the email from all users across the organization. This sub-playbook runs if the original email was retrieved and SearchAndDelete is set to
Truein the playbook inputs. During setup, we kept the default setting,False. If you decide to use this playbook with O365, change the SearchAndDelete setting toTrue, change SearchAndDeleteIntegration fromEWStoO365, and configure the O365 - Security And Compliance - Content Search v2 integration.The Block Indicators - Generic v2 sub-playbook contains sub-playbooks to blocks IPs, files, emails, and domains. For example, the Block IP - Generic v2 sub-playbook blocks IP addresses using one or more of the following integrations (depending on which integrations you have configured) PAN-OS, MineMeld, Zscaler, CheckPoint FW, and Fortinet. You can also customize the playbook to add additional integrations.
Manually remediate the incident.
To choose the remediation method(s), go to the Playbook Triggered task (at the beginning of this playbook), and set the BlockIndicators and the SearchAndDelete fields. If one or both are set to true, the playbook follows those branches. If the email is found to be malicious, the analyst assigned to the incident is prompted to manually remediate the incident, regardless of whether the search and delete emails and/or block indicators branches are executed.
After we have finished the remediation section, the timer stops and the investigation is closed.