--- name: phishing-email-triage description: > Triage a reported or suspicious email using the Polarity MCP integration stack. Use this skill whenever a user pastes email content, headers, or a description of a suspicious email and asks "is this phishing", "triage this email", "check this email", "is this legit", or shares a forwarded/reported message with a request to assess sender, links, or attachments. Also trigger when raw email headers (From/Reply-To/Return-Path/SPF/DKIM/DMARC lines) are pasted, or when a user asks to check a sender domain, an embedded link, or an attachment hash found in an email. Do not use for general spam classification without security intent, or for drafting/writing emails. --- # Phishing Email Triage Skill Turns a raw reported email into an enrichment-backed verdict and a ready-to-send user response, using Polarity's integrated threat intel and email-identity stack. --- ## Workflow Overview ``` 1. Extract signals → 2. Score header authenticity → 3. Enrich links/sender/attachments → 4. Correlate → 5. Verdict → 6. Render report + reply templates ``` --- ## Step 1 — Extract Signals Pull the following out of the pasted email (headers, body, or both): - **Sender address** and **display name** (flag mismatches, e.g. "IT Support" from a free webmail domain) - **Reply-To** and **Return-Path** (flag when they differ from From) - **SPF / DKIM / DMARC** results if headers are present - **All URLs** in the body, including ones hidden behind display text or shorteners - **Attachment filenames and hashes** if provided or extractable - **Urgency/social-engineering language** (payment requests, credential prompts, countdown language, authority impersonation) — note but do not over-index on this alone Use `polarity:parse_entities` on the full email text to catch anything missed manually. --- ## Step 2 — Score Header Authenticity | Signal | Points | |---|---| | SPF = fail or missing | +15 | | DKIM = fail or missing | +15 | | DMARC = fail | +10 | | From domain age < 90 days (via DomainTools IRIS `domaintools_iris_3_1_9_node_18_ba17ff4ea1_1697658218`) | +15 | | Reply-To / Return-Path domain ≠ From domain | +10 | | Display name impersonates a known brand/exec but domain doesn't match | +15 | --- ## Step 3 — Enrich Links, Sender, and Attachments Run in parallel via `polarity:do_integration_lookup`: | Entity | Integrations | |---|---| | Sender domain | `domaintools_iris_3_1_9_node_18_ba17ff4ea1_1697658218`, `cisco_umbrella_3_2_0_node_18_b764bf26c7_1697657935`, `cloudflare_domain_intel_3_0_0_node_18_468f31c94f_1762439591184`, `apivoid_3_1_3_node_18_5ed4fc6eac_1765902753366`, `majestic_million_3_1_5_node_18_65f1713366_1723152807` | | Sender email address | `emailrep`, `haveibeenpwnd_3_2_0_node_18_e72f988cf7_1721826241` | | Body URLs | `phishstats_3_1_4_node_18_440ea84824_1740732419`, `alienvault_otx`, `apivoid_3_1_3_node_18_5ed4fc6eac_1765902753366`, `cyberchef_3_2_6_node_18_3e5167c384_1697658112` (deobfuscate redirect chains/shorteners) | | Attachment hash | `malware_bazaar`, `hybrid_analysis_3_1_3_node_18_34359d3a4c_1697658498`, `metadefender_3_2_2_node_18_e90a8f8abf_1699555178`, `circl_hashlookup_3_0_3_node_18_b1d45ae411_1702912235` (known-good check) | | Any IP in headers (X-Originating-IP, Received chain) | `abuseipdb`, `greynoise`, `ipinfo` | Always also check: - `mxtoolbox_3_0_2_node_18_734813fe61_1702933075` — MX/blacklist health of the sender domain - `jira` — existing ticket for this sender/domain/campaign - `dataminr_3_0_0_node_18_1762356232_3_1_17_node_18_1768919523719` (Dataminr Pulse) — active phishing campaign news matching this theme --- ## Step 4 — Correlate - Do header failures and domain reputation agree, or is this a spoofed-but-clean domain (SPF fail on a legitimate but misconfigured sender)? - Is the link destination different from the display text (mismatch = strong signal)? - Has this exact sender/domain/URL pattern been reported before (Jira/MISP-style history)? - Is this part of a broader campaign (Dataminr Pulse, PhishStats recent submissions)? --- ## Step 5 — Verdict Combine the header score (Step 2, 0–60+) with enrichment hits into a single 0–100 score using the same scale as general triage: | Score | Verdict | Action | |---|---|---| | 70–100 | PHISHING | Block sender/domain, quarantine, notify affected users | | 40–69 | SUSPICIOUS | Quarantine pending review, do not auto-clear | | 15–39 | LOW RISK | Educate reporter, monitor | | 0–14 | LEGITIMATE | Release from quarantine if held | --- ## Step 6 — Render Report + Reply Templates Render the triage as an HTML widget via `visualize:show_widget`. Required sections: 1. **Header** — verdict badge + score, subject line, sender, report timestamp 2. **Header authenticity panel** — SPF/DKIM/DMARC as pass/fail pills, domain age, display-name check 3. **Link table** — each URL, its display text, actual destination, verdict per link 4. **Attachment panel** (if any) — filename, hash, AV/sandbox verdicts 5. **Campaign context** — matching Dataminr Pulse/PhishStats activity, prior tickets 6. **Recommended actions** — numbered, with time horizon badges (NOW/4 HRS/24 HRS) 7. **Footer** — integrations queried, confidence level Then, separately from the widget, use `message_compose_v1` to draft the two things a SOC analyst actually needs to send: - A short **quarantine/block confirmation** note for the security team channel - A plain-language **reply to the reporting employee** (thank them, tell them what happens next, remind them not to click links in the future) — only if the user asks for a reply, since sending mail requires their explicit review ### Visual Design Rules (all reports) Follow the claude.ai design system exactly: - **No hardcoded hex colors.** Use only CSS variables: `--color-background-primary/secondary/tertiary`, `--color-text-primary/secondary/tertiary`, `--color-border-tertiary/secondary`, `--color-background-danger/warning/info/success`, `--color-text-danger/warning/info/success`. - **Dark mode mandatory** — every element must be readable on a near-black background. - Font sizes: section labels 11–12px uppercase tracking, body 13–14px, metric numbers 20–24px. Font weights: 400 body, 500 headings/labels only. Never 600 or 700. - Cards: `background: var(--color-background-primary); border: 0.5px solid var(--color-border-tertiary); border-radius: 12px; padding: 1rem 1.25rem`. - Badges: `display: inline-block; padding: 4px 12px; border-radius: 6px; font-size: 12px; font-weight: 500` using semantic CSS vars for bg + text. - Section separators: `border-top: 0.5px solid var(--color-border-tertiary)`. - Tabler outline icons only (`