| name | implementing-soar-playbook-for-phishing |
| description | Automate phishing incident response using Splunk SOAR REST API to create containers, add artifacts, and trigger playbooks |
| domain | cybersecurity |
| subdomain | security-operations |
| tags | ["soar","splunk-phantom","phishing","incident-response"] |
| version | 1.0 |
| author | mahipal |
| license | Apache-2.0 |
| nist_csf | ["DE.CM-01","RS.MA-01","GV.OV-01","DE.AE-02"] |
Implementing SOAR Playbook for Phishing
Overview
This skill implements a phishing incident response workflow using the Splunk SOAR (formerly Phantom) REST API. When a suspected phishing email is reported, the agent parses email headers and body, creates a SOAR container representing the incident, attaches artifacts containing indicators of compromise (sender address, URLs, IP addresses, file hashes), triggers an automated investigation playbook, and polls for action results.
Splunk SOAR orchestrates and automates security operations through playbooks that chain together investigative and response actions. The REST API at /rest/container, /rest/artifact, and /rest/playbook_run enables programmatic incident creation and automation triggering from external tools, email gateways, and SIEM alerts.
When to Use
- When deploying or configuring implementing soar playbook for phishing capabilities in your environment
- When establishing security controls aligned to compliance requirements
- When building or improving security architecture for this domain
- When conducting security assessments that require this implementation
Common Misconfigurations & Verification
- Playbook doesn't auto-run on artifacts: if every
/rest/artifact POST sets run_automation: false (including the last one), the active playbook never triggers on ingest. Set run_automation: true on the final artifact, or start it explicitly via /rest/playbook_run.
- Playbook inactive or wrong label: a playbook scoped to a label/category that doesn't match the container's
label never fires. Confirm the container label matches the playbook's configured label and that the playbook is active, not just saved.
- Auth token lacks automation scope: a read-only
ph-auth-token creates containers fine but silently fails to start playbooks. Verify with a /rest/playbook_run POST and check for a 200 plus a playbook_run_id, not just successful container creation.
- Asset/app actions unconfigured: URL/domain reputation steps fail when the VirusTotal/reputation asset has no API key — the playbook "runs" but its actions error. Poll
/rest/action_run and confirm each action reaches success, not failed.
- Confirm end to end: submit a known-bad test
.eml, then verify a container was created, the playbook reached a terminal , and the verdict/artifacts populated. A created container with no is a silent failure.
