analyzing-phishing-emails

Analyzing Phishing Emails

A phishing email is an attack you were handed intact — which is a gift and a hazard. The gift is a full specimen: headers that trace the real origin, URLs and attachments that lead to the actor's infrastructure, and a lure that reveals intent. The hazard is that all of it is live. A URL fetched from your own IP tips the operator and can burn the investigation; an attachment opened on your box is the compromise. So the discipline is fixed: preserve the original, defang everything, and detonate only in isolation. The output is a verdict (malicious / suspicious / benign) plus IOCs the rest of the program can action.

Handle every specimen as sensitive: the email may contain a real user's PII. Keep it in the engagement store, never paste it into third-party services beyond the vetted reputation lookups below, and follow the data-handling rules in AGENTS.md.

When to Use

• A user-reported email or a .eml/.msg/mailbox artifact needs a disposition
• Tracing the true sender through a forged From and a relay chain
• Extracting URLs, attachments, and sender infrastructure into IOCs
• Confirming spoofing via SPF/DKIM/DMARC alignment
• Feeding a phishing verdict into detection or an incident

When NOT to Use

• The email led to a confirmed compromise — use responding-to-incidents; this skill triages the lure, that one runs the intrusion
• Deep analysis of the attachment's behavior — hand the sample to analyzing-malware; detonate there, do not "just open it"
• A packet capture of the callback traffic — use analyzing-network-traffic
• Building a mail-gateway or SIEM rule from what you found — use engineering-detections, writing-sigma-rules
• Packaging the IOCs into an actor/campaign product — use producing-threat-intelligence
• Sending phishing as the attacker (red-team simulation) — out of scope here; that is offensive social engineering, not lure triage

Preserve, Then Defang (do this before anything else)