> 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/cortex-xsoar-8-on-prem/8.10/configure-cortex-xsoar/playbooks/develop-your-playbook/customize-a-playbook-for-a-phishing-use-case-example.md). # Customize a playbook for a phishing use case example If your use case involves investigating a type of phishing event, you can customize a playbook from the Phishing content pack, for example the **Phishing - Generic V3** playbook. For an overview of the **Phishing - Generic V3** playbook, go to minute 4:06 in this video. [Stop Phishing Attacks in Minutes](https://www.youtube.com/watch?v=SY-3L348PoY) Do the following to customize the **Phishing - Generic v3** playbook.
Task 1. Edit the playbook 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.

Task 2. Review and change the playbook inputs Click **Playbook Triggered** at the top of the playbook. 1. **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. 2. **SearchAndDelete**: Turn on or off the Search and Delete Process in EWS O365. This is 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`**. 3. **BlockIndicators**: This is part of the remediation process. It automatically blocks malicious indicators in relevant integrations. For our example, we keep this as **`False`**. 4. **AuthenticationEmail**: Whether to authenticate the email. Leave as the default, **`true`**. See **Authenticate the email** under the investigation stage. 5. **OnCall**: Whether to assign a user that is currently on shift. Change this to **`True`**. 6. **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 from **`EWS`** to **`O365`**. If you use enable **SearchAndDelete** and set the **SearchAndDeleteIntegration** to O365, continue with the O365 inputs such as **O365DeleteType**. 7. **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`**. 8. **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. 9. **GetOriginalEmail**: Used to retrieve the original email, when the phishing email is forwarded and not attached. Change this to **`True`** only 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. 10. 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.
Task 3. Review the engage with user stage of the playbook 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. The playbook does two tasks simultaneously: * Engages with the user * Triage 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.
Task 4. Review the 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 **`ParseEmailFilesV2`** script. 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.
Task 5. Set up 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).
Task 6. Review the investigation section * 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](https://xsoar.pan.dev/docs/reference/playbooks/process-microsofts-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](https://xsoar.pan.dev/docs/reference/playbooks/detect--manage-phishing-campaigns) sub-playbook uses the **`FindEmailCampaign`** automation, which utilizes machine-learning to identify existing incidents in Cortex XSOAR that are part of the same campaign of the currently investigated incident. You can customize the inputs as required. If the sub-playbook finds that the incident is part of a campaign, it generates campaign-related data which you can observe in the linked **Phishing Campaign** incident, and take actions related to the campaign. * 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 **`setIncident`** script. * 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.
Task 7. Handle email as undetermined or 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.
Task 8. Set up 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 **`True`** in the playbook inputs. During setup, we kept the default setting, **`False`**. If you decide to use this playbook with O365, change the **SearchAndDelete** setting to **`True`**, change **SearchAndDeleteIntegration** from **`EWS`** to **`O365`**, 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 finishing the remediation section, the timer stops and the investigation is closed.
--- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://cortex-docs.paloaltonetworks.com/cortex-xsoar-8-on-prem/8.10/configure-cortex-xsoar/playbooks/develop-your-playbook/customize-a-playbook-for-a-phishing-use-case-example.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.