Phishing Playbook Template Walkthrough
By: Forrest Lybarger | Senior Splunk Consultant
Your analysts should spend more time doing analysis and investigation. Our Splunk SOAR (Cloud) Phishing playbook template walkthrough offers a visual platform for generating a playbook without writing code, so you can automate security procedures.
Below is a picture of the top-level phishing playbook template. I used comment blocks to note what should happen where in the playbook because playbook blocks require an existing playbook to name them and don’t allow notes. It is intended to give guidance on the process flow. Making templates for the sub-playbooks is largely unnecessary since those can vary between customers, and most are simple linear playbooks. I will cover the playbook going top to bottom.
Email Extraction:
Extract block for email file. This could change depending on how the phishing emails are being sent to Phantom. Extract IOC is a common method of parsing. The output will be various artifacts, for example, Email, URL, and Domain. Use extract IOC for .eml files.
Precheck:
Check email against a list of checks for whitelisting and blacklisting. This will save time and resources. Use custom lists to store whitelisted and blacklisted values like domains and IP addresses. Many internal emails can be whitelisted this way, especially if users are the ones flagging phishing emails.
Whitelisted:
Build a sub-playbook to process whitelisted events. It can perform many actions, including sending a notification email to the submitter or ticket creation coupled with immediate closure for record keeping. Talk to the customer about what they want to do.
Blacklisted:
Add a sub-playbook here to process blacklisted emails. Example actions to run: notification emails, ticket creation, isolation/triage. Talk to the customer about what they want to be done here.
Other:
Below, the playbook will branch out into multiple sub-playbooks to evaluate whichever items the consultant or customer deems helpful in determining the risk score of the email. They are broken up to maintain the readability of the top-level playbook while giving a detailed view of how the process works. A ticket in a 3rd party system like ServiceNow or JIRA can be opened here to record operations runs and their results (if the customer uses such a service). Don’t put all these sub-playbooks into a single playbook; that would be less readable and could result in one small part of the playbook interfering with more parts. Isolate them to improve readability and make maintenance easier.
Domain Evaluation:
Evaluate the domain artifacts created by using extract IOC. Discuss with the customer what API they will use to perform these checks. I recommend steering them toward any API that has an app on Phantom.
If the API they choose doesn’t have an app, then the consultant will have to code the API call themselves. Not only is this time-consuming, but once the consultant rolls off the project, someone else will have to maintain that code. The customer will likely not have control over the changes made to the API, so if the API changes, whoever maintains the code will have to edit it. Phantom apps are maintained by Splunk or the API developer, so the customer won’t have to do much maintenance.
URL Evaluation:
Evaluate URL artifacts in a sub-playbook by sending the URLs as inputs. Again, try to use an API with an existing Phantom app. If the API doesn’t have an entry for the URL, a submission should be run. Waiting for this submission to be finished will take time (5-15 min), so it would be better to just submit it in the playbook and have a manual review check for the score later when it’s done processing. Otherwise, custom code will have to be run to wait for the results, which will stall the whole playbook and could cause a backlog of emails.
IP Evaluation:
Evaluate the IP address of the email sender. When parsing .eml files with extract IOC, the IP address can be found in the Authentication-Results field in the email artifact. An ipv4 extract block can get the IP address without custom code. Customers might want multiple kinds of data to be evaluated here, like geolocation and reputation. Splunk has its own app for IP geolocation, which gives different fields for latitude, longitude, city, state, country, address, etc. A custom list will come in handy to whitelist/blacklist locations.
File Evaluation:
Use a sub-playbook to evaluate and/or detonate any attached files. Ignore image files since they won’t run anything and will be too common to process them all. Search for pre-existing entries using the hash included in the vault artifact corresponding to the file. If there isn’t an existing entry, submit the file; similar to the URL submissions, it is better to have the manual review check the score after the submission is done processing.
Score Assessment:
Using results from the branching eval playbooks, determine an overall score or a group of scores to be evaluated against thresholds in the following decision block. Example methodologies: weighted average, highest, weighted average of highest values. Use custom lists for weights.
Post check:
Evaluate the risk of the email by comparing it to thresholds inputted into this block. There are many different options to go with, but it will probably be best to start with low thresholds and increase them depending on volume and accuracy.
Safe:
Use another sub-playbook for processing emails determined to be safe. Example actions: send notification emails, open/close tickets, etc. Discuss these actions with the client.
Dangerous:
Use another sub-playbook for processing emails determined to be dangerous. Example actions: send notification emails, open/close tickets, etc. Discuss these actions with the client.
Want to learn more about creating a phishing playbook template in Splunk SOAR (Cloud)? Contact us today!