Phishing Indicators
DevOps & Securityphishing-indicatorsPhishing Indicators is an Agent Skill for devops & security published in the kortix-ai/suna repository on GitHub: a SKILL.md instruction file an AI agent can load to do this task.
The phishing-report triage runbook — how to check headers, links, and attachments on a reported email against {{report_query}}, classify the risk, and post a verdict with a recommended action to {{security_channel}}. Analyze and recommend only; never block, delete, or remediate.
How to use this skill
Bring this guide into your coding agent with a prompt tailored to the tool you use.
- Open your project in Codex.
- Copy and paste the prompt below.
- Review files and risks before approving any action.
Inspect the Agent Skill at https://github.com/kortix-ai/suna/blob/HEAD/packages/starter/templates/marketplace/runtime/skills/phishing-indicators/SKILL.md and all supporting files. Report provenance, permissions, scripts, dependencies, and security risks. Propose an exact installation into .agents/skills/phishing-indicators, but wait for my approval before writing files or running scripts.
Copying this prompt does not install or run the skill. Review third-party files before use.
Step 1 — Pull what's new
Search the phishing-report Gmail inbox with {{report_query}} for messages
reported since the last check. Read each one in full, including the original
message it wraps if it was forwarded — the reported wrapper email itself is
rarely the attack; the forwarded original is.
Step 2 — Check the headers
For the original (forwarded) message, inspect:
| Check | What to look for |
|---|---|
| SPF / DKIM / DMARC | Any result other than a clean pass on all three is a signal, not proof by itself |
| Reply-To vs. From | A Reply-To that doesn't match the From domain, especially to a free-mail or lookalike domain |
| Return-Path | A Return-Path domain unrelated to the claimed sender |
| Display name vs. address | A trusted display name ("IT Helpdesk") paired with an unrelated or misspelled address |
| Routing headers | Received chain hopping through unexpected countries or unrelated infrastructure for an internal-looking sender |
Step 3 — Check the links
For every link in the body:
- Resolve it to its actual destination — don't trust the display text; a link
that reads
microsoft.comcan point anywhere. - Flag lookalike domains (character substitution, added words, wrong TLD), URL shorteners, and raw IP-address links.
- Flag any destination that resembles a login page for an internal system, especially one asking for credentials or MFA codes.
- A benign, well-known domain with a legitimate path is not itself a signal.
Step 4 — Check the attachments
- Identify the attachment's real type (magic bytes / content), not just its
extension — a
.pdfthat's actually an executable or a macro-enabled document is a strong signal. - Flag macro-enabled Office formats, script files, disk images, and any archive that requires a password given only in the email body (a common evasion for content scanners).
- No attachment is not itself reassuring — credential-harvesting links don't need one.
Step 5 — Classify the risk
Combine the signals into one tier:
| Tier | Criteria |
|---|---|
| Critical | Credential-harvesting link or malicious attachment, spoofed authentication, actively impersonating an internal system or executive |
| High | Clear lookalike domain or header spoofing plus a suspicious link or attachment, but not yet confirmed credential harvesting |
| Medium | One or two suspicious indicators (e.g. authentication soft-fail plus an unusual link) without a clear malicious payload |
| Low | Minor anomalies (e.g. a marketing email with an aggressive tone) that don't indicate targeted attack |
| Benign | Clean authentication, legitimate sender and links, no attachment concerns — a false report |
Back every tier with the specific indicators found; don't assign a tier on tone or gut feel alone.
Step 6 — Draft the verdict and recommended action
Write a short verdict: the tier, the indicators that drove it, and one recommended action:
- Block this sender — for critical/high reports with a clearly malicious, reusable indicator (a spoofed domain, a confirmed bad link).
- Warn staff — when the same sender or link may have reached others, note who's likely affected and suggest a heads-up.
- No action needed — for low/benign reports; say so plainly so security doesn't waste time re-checking it.
Step 7 — Post to Slack and stop
Post the verdict to {{security_channel}}: tier, indicators, recommended action, and a link back to the reported thread. That post is the only output. There's no ledger to update — the next scheduled check re-reads whatever the inbox looks like then.