---
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 (`<i class="ti ti-NAME" aria-hidden="true">`). Never filled variants.
- Sentence case everywhere. No ALL CAPS section titles.
- No gradients, drop shadows, blur, or glow effects.
- Score/meter bars: plain `<div>` with width `${value}%`, no canvas or chart libraries.
- Always render via `visualize:show_widget` (HTML mode). Call `visualize:read_me` with
  `modules: ["mockup"]` first if not already done this session. One line of prose before the
  widget call, nothing after except an offer to drill into any section.

---

## Handling Edge Cases

**No headers pasted, body text only**: Skip the SPF/DKIM/DMARC score component and lean on link/
sender/attachment enrichment plus language analysis. Say explicitly that header analysis was skipped.

**Internal sender (looks like it's from a colleague)**: Check for Business Email Compromise —
verify via `okta_3_0_11_node_18_815368fef1_1743269873` or `microsoft_entra_id_3_0_0_node_18_9f3c7c025d_1779802234180`
whether the claimed sender's account shows anomalous sign-in activity, rather than assuming external spoof.

**Shortened/redirect URLs**: Use `cyberchef_3_2_6_node_18_3e5167c384_1697658112` to unwind the chain
before scoring the final destination — scoring the shortener itself is meaningless.

**QR-code phishing ("quishing")**: If the user describes a QR code instead of a link, ask for the
decoded URL (or decode it themselves) before proceeding — Polarity has no native image OCR here.

**Zero hits everywhere**: Do not default to LEGITIMATE. Note that clean infrastructure is common in
targeted spear-phishing; weight the header-authenticity score and language signals more heavily and
say so in the report.
