> For the complete documentation index, see [llms.txt](https://cortex-docs.paloaltonetworks.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://cortex-docs.paloaltonetworks.com/tutorials/cortex-xsoar-tutorials/readme/set-up-a-phishing-incident-in-cortex-xsoar.md).
# Set up a Phishing Incident in Cortex XSOAR
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, users can be 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.
For this tutorial, you will need a dedicated phishing inbox using EWS, a VirusTotal API key, Active Directory, and Palo Alto Networks Wildfire. You can also configure alternative integrations, following the basic principles of this tutorial. For example, instead of EWS, you could use Gmail. If you have another sandbox integration available, you can substitute that for Palo Alto Networks Wildfire. For threat intelligence, you might use Recorded Future v2 instead of VirusTotal.
{% hint style="info" %}
### Note
Cortex XSOAR v6.9 and later includes the Cortex XSOAR Deployment Wizard for Phishing. After installing the Phishing content pack, the Deployment Wizard provides assistance with configuring integrations and playbook parameters. This tutorial provides step by step guidance for planning and implementing your response to phishing incidents, and can be used either as a supplement to the Deployment Wizard or on its own. If you use this tutorial with the Deployment Wizard, certain steps, such as navigating to specific pages to modify settings, are automated.
{% endhint %}
{% hint style="info" %}
### Note
You can also manage phishing alert incidents generated from email security gateways using the [PhishingAlerts content pack](https://xsoar.pan.dev/marketplace/details/PhishingAlerts).
{% endhint %}
To get up and running with a phishing incident in Cortex XSOAR, follow these stages.
| Stage | Section | Description |
| ----- | ------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| 1. | [Planning](#UUID-02a5ff04-e924-a61e-2792-101ffed4f43e_UUID-80c1a9a8-43e6-15ac-c33d-66c0443284a3) | Before installing Cortex XSOAR, plan how you are going to ingest incidents into Cortex XSOAR, what analysts need to investigate, how to deal with the response, what integrations you need, etc. |
| 2. | [Install and Configure Content Packs](#UUID-02a5ff04-e924-a61e-2792-101ffed4f43e_UUID-9bc03032-ef73-8d86-c2fd-e79464c8c732) | To begin, install the relevant content packs from the Cortex XSOAR Marketplace and add the required instances. In this example, we are going to add the Phishing content pack, the Microsoft Exchange Online content pack, which includes the EWS O365 integration to ingest incidents, the VirusTotal content pack for the VirusTotal integration for data enrichment, etc. In addition, we will install the Phishing Campaign and Phishing URL content packs. |
| 3 | [Customize the Phishing Layout](#UUID-02a5ff04-e924-a61e-2792-101ffed4f43e_UUID-d0bc85e6-02ef-7256-3476-a55485be4ff7) | Review the phishing incident layout, create new custom fields, and edit the phishing incident layout. |
| 4. | [Classify and Map Fields](#UUID-02a5ff04-e924-a61e-2792-101ffed4f43e_UUID-29082c08-eb0b-bbfc-e909-4c7ad5789e27) | 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 Rule](#UUID-02a5ff04-e924-a61e-2792-101ffed4f43e_UUID-eae5ef9a-3fde-8546-8412-045a1b5a6ff0) | Add pre-process rules to perform certain actions on incidents as they are ingested into Cortex XSOAR. For example, drop identical incidents and link to existing incidents. |
| 6. | [Review and Customize Phishing Playbooks](#UUID-02a5ff04-e924-a61e-2792-101ffed4f43e_UUID-a267d239-872a-d9fa-7ecc-21f7f118a790) | 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 - Generic v3** playbook. |
| 7. | [Create Post-Process Rules](#UUID-02a5ff04-e924-a61e-2792-101ffed4f43e_UUID-ef28126e-9552-e3dd-1ad1-d2df18e3a8dc) | Once the incident is complete and you are ready to close it, you can run various post-processing actions on the incident. |
| 8. | [Summary](#UUID-02a5ff04-e924-a61e-2792-101ffed4f43e_UUID-f9e52e2b-6d36-31c2-7f6e-6835db3f3150) | Once everything is set up, analysts can start investigating incidents. |
### 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. We want to fetch all phishing emails, whether they are forwarded or attached into Cortex XSOAR, using EWS O365. We want to use impersonation rights to get the original email from a user’s inbox. Although not essential, we also 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 likely want to see the source email, destination email, email headers, body, email HTML, email text, attachment 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 is your current incident response process?
You may want to check IP addresses for location, act according to the country to increase severity, block IPs, manually investigate further, and close incidents. You may also want to search and delete malicious emails, check for clicked URLs, and block a domain or an email address.
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.
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 file attachments. You can run this automatically in the playbook or manually. 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?
* Do you want to confirm before deleting an email from another user’s account?
* Will you notify an analyst to 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? 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.
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 such as Jira or *ServiceNow*, 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. 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. The **Detect & Manage Phishing Campaigns** playbook in the **Phishing Campaign** content pack finds duplicate incidents and creates an incident to investigate the phishing campaign.
After you have finished the planning stage, you can proceed to install the necessary content packs to manage phishing incidents in Cortex XSOAR.
### Install and Configure Content Packs
To begin, we need to install and configure the relevant content packs.
| Content Pack | Content | Description |
| ------------------------------ | ------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------- |
| Phishing | Automations, Playbooks, Incident Fields, Incident Layouts, Incident Types, Playbooks | Phishing content pack |
| Microsoft Exchange Online | [EWS O365](https://xsoar.pan.dev/docs/reference/integrations/ews-v2) | Mail listener/sender |
| VirusTotal | [VirusTotal - (API v3)](https://xsoar.pan.dev/docs/reference/integrations/virus-total-api-v3) | Data enrichment and threat intelligence |
| WildFire by Palo Alto Networks | [Palo Alto Networks WildFire V2](https://xsoar.pan.dev/docs/reference/integrations/wild-fire-v2) | Forensic and Malware analysis |
| Phishing Campaign | Automations, Incident Fields, Incident Type, Layout, Playbook | Detect whether a phishing incident is part of a phishing campaign |
| Phishing URL | DBotPredictURLPhishing and DBotUpdateLogoURLPhishing automations | Predict phishing URLs using a pre-trained model. Add, remove, or modify logos from the URL Phishing model. |
We will also use the [Rasterize](https://xsoar.pan.dev/docs/reference/integrations/rasterize#configure-rasterize-on-cortex-xsoar) and [Active Directory](https://xsoar.pan.dev/docs/reference/integrations/active-directory-query-v2) integrations, which are pre-installed.
**Install the Phishing Content Pack and Configure the EWS Email Gateway**
1. Go to Marketplace, search for **`Phishing`** and install the **Phishing** content pack.
2. During installation, select **Microsoft Exchange Online** as the email gateway. The **Microsoft Exchange Online** content pack will install at the same time as the **Phishing** content pack.
3. After the content packs are installed, go to **Settings** → **INTEGRATIONS** → **Instances** and search for **`EWS O365`**.
4. Add the **EWS O365** integration instance, which fetches events, attachments, and original emails from an inbox, and searches and deletes emails.
1. Click **Add instance**.
2. Choose **Fetches incidents**.
3. Verify the classifier is set to **EWS - Classifier**, which classifies incoming incidents as Phishing. If you were configuring an integration instance that did not have a classifier available, you would select **Phishing** for the **Incident type (if classifier doesn’t exist)** option.
4. Follow the instructions to authorize the Demisto app and enter the ID, Token, and Key that you receive.
5. Add the email address of the designated phishing inbox from which to fetch incidents.
6. If you want to designate a specific folder from which to fetch emails as phishing incidents, enter that folder name. Otherwise, leave the default as **Inbox**.
7. Add any other options as required.
8. After you click **Test**, Cortex XSOAR attempts 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).
9. **Save & exit**
The system starts ingesting incidents from EWS. Every email creates an incident in Cortex XSOAR.
**Configure the VirusTotal (API v3), Palo Alto Networks Wildfire, and Active Directory Query Instances**
* **`VirusTotal`** investigates suspicious files, domains, URLs, IP addresses, etc.
* **`Palo Alto Networks WildFire v2`** Submits files, returns the report, and looks up the file reputation.
* **`Active Directory Query 2`** Accesses and manages Active Directory objects (users, contacts, and computers) and runs AD queries.
VirusTotal (API v3)
1. Go to Settings → **INTEGRATIONS** → **Instances** and search for **`VirusTotal (API v3) (Partner Contribution)`**.
2. Click **Add instance**.
3. Add the VirusTotal API key.
For testing purposes, if you do not have a VirusTotal subscription, you can use the VirusTotal public API, which is limited to 500 requests per day, at a rate of 4 requests per minute, and cannot be used in commercial products or services. The VirusTotal premium API does not have these limitations.
4. Click **Test** and then **Save & Exit**.
Palo Alto Networks WildFire v2
1. Go to Settings → **INTEGRATIONS** → **Instances** and search for **`Palo Alto Networks WildFire v2`**.
2. Click **Add instance**.
3. Add the API key.
4. Click **Test** and then **Save & Exit**.
Active Directory Query v2
1. Go to Settings → **INTEGRATIONS** → **Instances** and search for **`Active Directory Query v2`**.
2. Click **Add instance**.
3. Add the Server IP address, Port, Credentials, Password, and Base DN.
4. Click **Test** and then **Save & Exit**.
**Install the Phishing Campaign Content Pack**
We want to detect whether a phishing incident is part of a phishing campaign. Go to the **Marketplace** page and Install the [Phishing Campaign](https://xsoar.pan.dev/docs/reference/packs/phishing-campaign) content pack to find, create, and manage phishing campaigns. The Phishing Campaign content pack provides useful information such as an aggregation of all the indicators from all emails, the number of senders and recipients, the analysts investigating the different incidents, etc. 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 on the campaign 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.
**Install the Phishing URL Content Pack**
The Phishing URL content pack contains the **DBotPredictURLPhishing** automation used in the **Phishing - Machine Learning Analysis** sub-playbook. The automation loads a pre-trained model to detect URL phishing attacks.
#### Review the Phishing Incident Type
Cortex XSOAR supports multiple incident types. When incidents are ingested into Cortex XSOAR, they are classified by type. The Microsoft Exchange Online content pack, which we installed with the Phishing content pack, includes a classifier which assigns phishing email messages to the phishing type. For the phishing incident type, you can customize layouts, assign a default playbook, and define rules to extract indicators from incident fields and enrich them using commands and scripts.
To edit an incident type, the incident type must be detached or you must duplicate the incident type and edit the copy. When an incident type is detached, it no longer receives updates to the incident type from the related content pack. If you want to receive updates, duplicate the incident type instead of detaching it. The original incident type continues to receive updates, in this case, but the duplicate does not. For this tutorial, we will detach the incident type.
1. Go to Settings → OBJECTS SETUP → Incidents → Types.
2. Select the **Phishing** type and click **Detach**
3. Select the **`Phishing`** incident type and click **Edit**.
4. From the **Settings** tab, review the following:
* In the **Default playbook** field, confirm the **Phishing - Generic v3** playbook is selected.
* In the **Layout** field, keep the default **Phishing Incident v3** layout. We will later customize this layout.
We will create a post process rule later, but for now we will leave this blank.
5. In the Indicators Extraction Rules tab, review the fields that are being extracted.
You can see there are hundreds of incident fields, but only relevant fields are being extracted for phishing (Email Body, Email Reply To, Email Body HTML, Email Subject, etc. ). These extraction rules are specific to the Phishing incident type, and we want to keep these out-of-the-box settings for now. We can make changes to indicator extraction rules later, if we see that unnecessary indicators are being extracted or if we are missing extraction for specific fields.
6. If you have made any changes, click **Save**.
### Customize the Phishing Layout
Each incident type has a layout. When building or customizing an incident layout, you want to display the most relevant data for analysts at all stages of the incident life cycle, from ingestion to remediation. For example, in the **Investigation** tab of the phishing layout, you can see information about the email (ID, subject, sender, etc.), the email text, attachments, the email image (using Rasterize), indicators, etc. In this section, we will review the phishing layout as it comes out of the box, create additional custom fields, and add fields to the phishing layout.
**Review the Phishing Layout**
You can familiarize yourself with the phishing layout before you make any changes. The phishing content pack includes fields specific to phishing investigations, including attachment type, size, email body, email headers, reporter email address, etc., which are included in the phishing incident layout. You can create new sections, add buttons, add custom fields, etc. To view the layout, select Settings → OBJECTS SETUP → Incidents → Layouts → **Phishing Incident v3**.
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 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 (tasks that require manual intervention, such as manual tasks or tasks with an error status), team members, a link to a Phishing Campaign incident (if relevant), etc.
**Investigation**
The investigation tab provides more in-depth information, including email headers and analysis, machine learning checks, macro code (if present in an attachment), the email text, HTML image, attachments, indicators, and information such as the email sender, subject, and ID.
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.
In addition to ingesting phishing incidents from an email inbox, you can also manually create a phishing incident in Cortex XSOAR. The new incident layout for phishing incidents enables you to populate a phishing incident by uploading the email as an EML or MSG file.
* **Close Form**
Contains information relevant to closing a phishing incident.
* **Incident Quick View**
Contains summary information relating to the phishing incident.
**Create Custom Fields for the Phishing Layout**
You are now familiar with the out-of-the-box phishing layout, but you can also create custom fields to add 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. |
| Sensitivity | Short text | We will add this to the Case info tab and when creating or editing an incident.
Sensitivity refers to the classification level of the email, set by the user sending the email, if the email contains sensitive content.
|
1. Go to Settings → OBJECTS SETUP → Incidents → **Incident Fields**.
2. Create the Boolean fields, such as **Was there a High Value Target?**
1. Click **New Field**.
2. In the **Field Type** field, select **Boolean (checkbox)**.
3. In the **Field Name** field, type the name you want to use, such as **`High Value Target`**.
By default, this field is available for all incident types. To choose specific incident types, deselect the checkbox for **Add to all Incident types** and select the desired incident type(s) from the dropdown menu.
4. Click **Save**.
5. Repeat for the other Boolean fields.
3. Create the short text field.
1. Click **New Field**.
2. In the **Field Type** field, select **Short text**.
3. For the **Field Name** field, type **`Sensitivity`**.
4. Click **Save**.
{% hint style="info" %}
### Note
You can also add existing incident fields, either out-of-the-box fields or fields from other content packs, to your Phishing incident layout. For example, if you wanted to include the **User** field from the Malware content pack in your Phishing incident layout, you would edit the **User** field and add **`Phishing`** from the **Add to Incident types** dropdown. The field would then be available to add to your Phishing incident layout.
{% endhint %}
**Add Fields to the Phishing Incident Layout**
We are going to add both custom fields and existing out-of-the-box fields to the phishing layout.
To edit an incident layout, the layout must be detached or you must duplicate the incident type and edit the copy. When an incident type is detached, it no longer receives updates to the incident type from the related content pack. If you want to receive updates, duplicate the incident type instead of detaching it. The original incident type continues to receive updates, in this case, but the duplicate does not.
1. Go to Settings → OBJECTS SETUP → Incidents → **Layouts**.
2. Select the **Phishing Incident v3** layout checkbox.
3. Click **Detach**.
4. Select the **Phishing Incident v3** layout and click **Edit**.
5. In the **Case info** tab, add the custom fields.
We can add these custom fields to any section. In this example, we want to create a new section.
1. From the **Library** section, in the **Sections** tab, drag and drop the **New Section** onto the **Case info** tab.
2. Rename the section to **Additional Email Information** by clicking the pencil icon and selecting **Edit section settings**.
3. In the **Fields and Buttons** tab, drag and drop the custom buttons we have created.
6. Add existing system fields.
1. Drag and drop the **XSOAR Read Only Roles** field to the existing **Case Basic Details** section,
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 fields to the **Incident Metadata** section.
8. Click **Save Version**.
This enables you to restore any changes made. You have the option to include a note about your changes.
### Classify and Map EWS Fields
Classification determines the type of incident that is created for events ingested from a specific integration (EWS O365). Mapping matches the fields from your third-party integration to the fields that you associate with the phishing incident (often 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 → OBJECTS SETUP → Incidents → Classification & Mapping → **EWS - Incoming Mapper** checkbox.
2. Click **Duplicate**.
3. Click **EWS - Incoming Mapper\_copy**.
4. In the **Incident Type** dropdown, change from the default **`Common Mapping`** to **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. Add one of the custom fields we created.
1. For the **Sensitivity** field, click **Choose data path**.
2. In the **root** section (right-hand side of the window), click **sensitivity**.
3. Repeat these steps if you have any unmapped custom fields.
4. Save the changes to the mapper.
7. Click **Auto Map** to automatically map the remaining fields based on naming convention. In this example, **`SHA256`** maps to **`attachmentsSHA256.`**
8. By default, the instance is set to use the **EWS - Incoming Mapper** and now needs to be changed to the duplicate mapper we have created and edited. Go to **Settings** → **INTEGRATIONS** → **Instances** and click the gear icon to edit the settings for the **EWS O365** instance. Change the mapper to **EWS - Incoming Mapper\_copy**, **Save & exit**.
### Add Pre-Process Rule
Pre-process rules enable you to perform certain actions on events as soon as they are ingested into Cortex XSOAR. We can use pre-process rules to drop incidents, close duplicate incidents, link incidents together, run a script, etc. In this example, our organization has been running a phishing awareness campaign to check if internal users properly report phishing emails. We don't want to investigate these incidents, as we know they are not truly malicious emails.
1. Select Settings → Integrations → Pre-Process Rules → **New Rule**.
From Cortex XSOAR v6.11 and later, go to **Settings** → **OBJECTS SETUP** → **Incidents** → **Pre-Process Rules** → **New Rule**.
2. In the **Rule Name** field, type, **`Phishing Awareness Campaign`**.
3. In the **Conditions for Incoming incident** section, add the following filter:
4. In the **Action** field, select **Drop**.
5. Click **Save**.
All future incidents that include this subject are dropped. If the awareness campaign concludes or a new email subject is used, you may want to remove or edit this pre-process rule.
### 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 several sub-processes that require step-by-step actions to be performed. You can use playbooks to detect, identify, analyze and remediate an event.
The Phishing content pack comes out of the box with several playbooks, such as the **`Phishing - Generic v3`**, **`Process Email - Generic v2`**, **Calculate Severity By Email Authenticity**, etc. You can customize these out-of-the-box playbooks, or create your own playbook.
#### Customize the Phishing - Generic v3 Playbook
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.
1. Go to **Playbooks** and Search for **Phishing - Generic v3**.
2. 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.
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.