CYBRARY # Template: phishing report triage
# Mirrors the Splunk SOAR community "Phishing Investigate and Respond" flow.
# Enrich the report, record what it is, and only then ask about the mailbox.
playbook Phishing report triage
step collect_report
action case.attach-evidence
locator case/mail/reported-message
label Reported message, headers and body as received
risk read
retry 2
step collect_url_verdict
action case.attach-evidence
locator case/intel/url-reputation
label URL reputation for every link in the message
risk read
retry 2
step record_verdict
action case.update
field verdict = true-positive
field category = credential-phishing
risk read
step ask_purge
action prompt
label Purge this message from all mailboxes that received it?
approvers soc-lead
risk consequential
step purge_message
action estate.set-attribute
entity MAIL-CAMPAIGN-1
set mailbox_delivery = purged
risk consequential
approval required
on-error stop
step close_case
action case.update
field status = closed
field closure_note = Credential phish purged from delivered mailboxes; sender blocked.
risk read
When to use it. A user reports a suspicious mail and you want the same enrichment on every report, whoever is on shift.
In Splunk SOAR. Splunk SOAR: 'Phishing Investigate and Respond' — url reputation and file reputation blocks, a decision block on the verdict, then a prompt ahead of the delete-email action.
Why it is built this way
- URL and attachment reputation are reads: retry them, because a rate-limited connector is not a verdict.
- The purge is gated. Removing mail from mailboxes is visible to every recipient and hard to undo.
- The closure note names what was purged and what was blocked — the next analyst reads that line, not the graph.
What reviewers reject
- Purging before recording a verdict, which leaves a case that changed the world for no stated reason.
- Retrying the purge. Retries belong on reads, not on an action that already half-succeeded.