Automating response to phishing attacks remains one of the core use-cases of SOAR platforms. In 2022, the Anti-Phishing Working Group (APWG) logged ~4.7 million phishing attacks. Since 2019, the number of phishing attacks has increased by more than 150% yearly. Phishing is also a common delivery method for more destructive attacks. For example, an article by Credit Union Times states that in organizations with more than 250 employees, 75% of ransomware attacks were started via email. In a survey conducted by Osterman Research, it was found that IT and Security teams take an average of 27.5 minutes to handle a single phishing email and the estimated cost of discovering and mitigating a single phishing email is $31.32.
In this ‘How to Build a Playbook’ series, we’ll be focusing on Office 365. We’ll be using supportive tools including CrowdStrike Falcon, Recorded Future, Active Directory, and Checkpoint Firewall. The combination of these tools will deliver a complete, end-to-end incident response workflow that will eliminate manual triage and data-gathering, help the investigation team make more accurate decisions, and automate containment and recovery when the analyst determines how to proceed with an incident.
When starting to build a new playbook, it’s important to identify the available integration commands to narrow down the list of possible commands you’ll use. With hundreds of integrations out of the box, it can feel overwhelming to select the right ones.
For this phishing playbook, we’ll be using Office 365 to ingest suspicious emails, CrowdStrike, Active Directory, and Checkpoint Firewall for enrichment and incident response, and Recorded Future for open source intelligence (OSINT). In D3 Smart SOAR, there are over 100 commands across the five integrations, so we need to narrow down the list further to make our possible playbook design clearer.
To do that, we’ll follow a two-step process:
1. List the artifacts that the playbook needs to process
2. Identify which integration commands can process those artifacts.
Full list of integration commands
Possible Artifacts
For this step, it’s helpful to secure raw data of a sample alert and use it to identify which artifacts the playbook will need to process.
{
"Authentication-Results": "spf=softfail (sender IP is 3.93.93.217)
smtp.mailfrom=archiefilmco.com; dkim=fail (body hash did not verify) header.d=archiefilmco.com;dmarc=fail action=none header.from=archiefilmco.com;compauth=fail reason=001",
"createdDateTime": "2023-08-30T21:37:19Z",
"lastModifiedDateTime": "2023-08-30T21:37:19Z",
"sentDateTime": "2023-08-30T21:36:16Z",
"hasAttachments": true,
"internetMessageId": "<CALY3rr-e-BtAyuajm7duDK_VO=9kGjPjihrK=aOwgMrKMOBXtw@mail.gmail.comarchiefilmco.com>",
"conversationIndex": "AQHZ24onrnCcVh97vEO27a8bnDJJ8g==",
"isReadReceiptRequested": false,
"isRead": true,
"isDraft": false,
"internetMessageHeaders": [
{
"name": "Message-ID",
"value": "<CALY3rr-e-BtAyuajm7duDK_VO=9kGjPjihrK=aOwgMrKMOBXtw@mail.gmail.com>"
},
{
"name": "Subject",
"value": "Jira test"
},
{
"name": "From",
"value": "\"Marissa Masters\" <[email protected]>"
},
{
"name": "To",
"value": "\"Kartik Subramanian\" <[email protected]>"
}
],
"body": {
"content": "http://www.google.com"
},
"flag": {
"flagStatus": "notFlagged"
},
"attachments": [
{
"@odata.type": "#microsoft.graph.fileAttachment",
"@odata.mediaContentType": "text/plain",
"lastModifiedDateTime": "2023-08-30T21:37:19Z",
"name": "jira_email.txt",
"contentType": "text/plain",
"size": 1918,
"isInline": false,
"contentId": "f_lly9bdx20",
"contentLocation": null,
"contentBytes": "YXRlZ3kgc2Vzc2lvbiBjb3VsZCB2ZXJ5IHdlbGwgdHJhbnNsYXRlIHRvIHF1aWNrZXIgZGVjaXNpb24tbWFraW5nIGluIGFuIE1NQSBtYXRjaCwgYW5kIHZpY2UgdmVyc2EuDQoNCklyb25pY2FsbHksIGNoYXNpbmcgZmxvdyBjYW4gYmUgY291bnRlcnByb2R1Y3RpdmUuIEl0J3MgYSBzdGF0ZSB0aGF0IHRlbmRzIHRvIGhhcHBlbiB3aGVuIHlvdSdyZSBmdWxseSBlbmdhZ2VkIGluIHRoZSBwcmVzZW50LCBub3Qgd2hlbiB5b3UncmUgdGhpbmtpbmcgYWJvdXQgYmVpbmcgaW4gZmxvdy4gU28sIHRoZSBiZXN0IGFwcHJvYWNoIGlzIHRvIHNldCB0aGUgc3RhZ2UgYW5kIGxldCBpdCBoYXBwZW4gbmF0dXJhbGx5Lg==",
"D3FileId": "19"
}
]
}
Based on the data above, we know that the playbook will need to handle a domain name, sender and recipient emails, IP address, URL, message ID, and file hash. For phishing playbooks, we can make another assumption as well: the recipient’s email can be put into Active Directory to get their username. Then, their username can be used as an input in CrowdStrike to get the list of devices assigned to the user. So, let’s make sure our playbook can handle usernames and device IDs as well.
Relevant Integration Commands
Now that we know which artifacts are contained in the suspicious email alerts, we can narrow down our list of integration commands to only the ones that take those artifacts as inputs. Once the list is narrowed, we’ll categorize each command into one of three groups: enrichment, containment, and recovery.
Narrowed list of integration commands.
Next Steps
Now that we have an organized list of integration commands we are ready to start designing our playbook. In the next part in this series, we will wireframe the workflow and select which commands we want to run when. This will prepare us for part three where we actually build the playbook and run sample data through it.
In This Series:
How to Build a Phishing Playbook Part 2: Wireframing
How to Build a Phishing Playbook Part 3: Playbook Development
How to Build a Phishing Playbook Part 4: Testing and Publishing
