n8n Phishing Response Automation Playbook

Why Phishing Is the Highest-Return Playbook

Phishing dominates SOC alert volume. User-reported suspicious emails arrive constantly, and the vast majority follow the same triage path: read the email, extract the sender and links, check reputation, decide whether it is malicious, and if so find out who else received it and clean it up. That repetition is exactly what automation is built for, and it is why phishing response is usually the first or second playbook Codesecure builds on any n8n SOAR engagement.

The economics are compelling. Manual phishing triage typically consumes ten to thirty minutes per report once you account for extraction, multiple reputation lookups, mailbox searches and remediation. A SOC handling dozens of reports a week is spending a meaningful fraction of an analyst's time on mechanical work. A playbook that handles intake, extraction and enrichment automatically, and stages the containment for one-click approval, gives most of that time back.

Speed also limits damage. The window between the first click and a compromised credential or a deployed payload is short. A playbook that identifies a malicious campaign and is ready to purge it from every inbox within minutes, rather than hours later when an analyst gets to the queue, directly reduces how many users fall victim. In phishing response, time saved is harm prevented, not just effort saved.

Intake and Indicator Extraction

A phishing playbook is only as good as its input, so start with structured intake. The best source is a report-phishing button: the Microsoft Report Message or Report Phishing add-in, the Google Workspace equivalent, or a dedicated reporting mailbox that users forward to as an attachment. These give the workflow the original email with full headers intact, rather than a screenshot or an inline forward that has stripped the technical detail you need.

n8n triggers on the new report, either via a mailbox-watch node, a Microsoft 365 or Google Workspace integration, or a webhook from the reporting add-in. The workflow then parses the raw email: it reads the headers to establish the true sender, the sending infrastructure and authentication results (SPF, DKIM, DMARC), extracts the from and reply-to addresses, pulls every URL out of the body, and collects any attachments and their hashes.

URL extraction needs care because phishing links hide behind redirects, URL shorteners and tracking wrappers. The workflow should unwrap known safe-link rewriters and shorteners to reveal the true destination, and defang the URLs (rendering them non-clickable) wherever they are displayed to analysts, so nobody accidentally clicks a live malicious link while triaging. Attachments are hashed rather than opened, and any office documents or archives are flagged for sandbox detonation rather than handled inline.

The output of this stage is a clean, structured set of indicators: sender address and domain, sending IP, authentication verdicts, defanged URLs and their resolved destinations, attachment hashes and names. This structured object is what every downstream stage operates on, and getting it right is what makes the rest of the playbook reliable.

Enrichment and Reaching a Verdict

With indicators extracted, the playbook enriches them using the same parallel-lookup pattern as any enrichment workflow. Sender domain and IP go to reputation feeds and GeoIP; URLs go to URL reputation services and, where available, a sandbox or URL-detonation engine; attachment hashes go to VirusTotal and your own malware intelligence; everything is correlated against MISP for matches to known campaigns.

Authentication results are a strong early signal. An email claiming to be from your bank or a known supplier that fails SPF, DKIM and DMARC is far more likely to be spoofed. Combined with a recently registered sender domain, a mismatched reply-to address, or a link to a look-alike domain, the workflow can assemble a confidence score that a message is phishing well before any human reads it.

The verdict stage combines these signals into a classification: clearly malicious, clearly benign, or uncertain. Clearly malicious messages, a known-bad URL, a flagged attachment hash, a confirmed campaign match in MISP, can proceed toward containment with high confidence. Clearly benign messages, a legitimate sender passing authentication with clean indicators, can be auto-closed with a courteous note to the reporter. The uncertain middle is where human judgement is essential and must not be automated away.

Be deliberately conservative about what counts as clearly malicious for the purpose of automated containment. The cost of purging a legitimate but unusual marketing email from every inbox, or blocking a real supplier's domain, is high and visible. The playbook should require strong, multi-source evidence before it even offers containment as an option, and should always present the evidence to the approving analyst rather than asking them to trust a bare verdict.

Containment: Mailbox Search, Purge and Block

Containment is where a phishing playbook earns its value and also where it carries real risk, so this is the stage that sits behind analyst approval. Once a message is confirmed malicious, the most important action is scope assessment: search every mailbox in the organisation for the same message by sender, subject and indicators to find every recipient, not just the one who reported it. A single report usually represents a campaign that hit dozens or hundreds of inboxes.

With the scope known, the workflow can purge the message from all affected mailboxes. In Microsoft 365 this is a soft or hard delete via the compliance search and purge capability; in Google Workspace it is the equivalent admin removal. This is a powerful, irreversible-feeling action across the whole organisation, which is exactly why it should execute only after an analyst reviews the evidence and the affected-recipient list and clicks approve. The playbook presents the scope and the evidence; the human authorises the purge.

Alongside removal, the playbook applies blocking controls: add the sender and the malicious domains to the tenant block list, submit the URLs to your secure web gateway or DNS filtering for blocking, and push the indicators to Wazuh and your EDR as detection rules so any future occurrence is caught automatically. These controls turn a single incident into durable protection against the same campaign.

Sequence and reversibility matter. Apply the easily reversible controls automatically (adding detection indicators, notifying), and gate the disruptive ones (organisation-wide purge, domain blocks) behind approval. Set blocks with a review or expiry where appropriate so the block list does not accumulate stale entries forever, and log every containment action with the approving analyst and timestamp for the incident record and any audit.

User Notification and Closing the Loop

Containment removes the email; notification handles the people. The playbook should close the loop with three audiences. First, the reporter: a prompt, courteous acknowledgement that their report was received and acted on. This single automated message is one of the highest-value parts of the playbook, because reporters who feel ignored stop reporting, and user reports are a primary detection source.

Second, the recipients who actually interacted with the email, clicked the link or opened the attachment, need a targeted, non-alarming notification explaining what happened and what to do, typically reset their password and watch for follow-on activity. The workflow can identify these users from mail-flow and click telemetry where available, so the warning goes only to those who need it rather than spamming the whole company.

Third, where a campaign is broad or convincing, a brief awareness note to the wider user base, this campaign is circulating, here is how to recognise it, both contains further clicks and reinforces security culture. Keep this proportionate; over-notifying trains users to ignore security messages, so reserve broad communications for genuinely significant campaigns.

Finally, the playbook documents the incident end to end: the original report, the extracted indicators, the enrichment verdict, the containment scope and actions, the approving analyst, and the notifications sent. This record, written to TheHive or your case system automatically, is the evidence trail for metrics, for repeat-campaign detection, and for any compliance obligation to demonstrate that reported phishing is handled consistently and promptly.