Analyzing Phishing Emails

Analyzing Phishing Emails

An email is a stack of claims — who sent it, where it came from, that its links are safe — and phishing analysis is checking each claim against evidence the sender could not forge: the Received chain, the authentication results, and the true destination of every link and attachment. The From header is a display, not a fact. Anyone can type any address into it; your job is to find the evidence that agrees or disagrees.

When to Use

• A user reports a suspicious email and you need a verdict and IOCs
• You have a .eml or .msg file to analyze offline
• You are handed raw headers and asked whether a message is spoofed
• A message carries a link or attachment that needs safe triage
• A business email compromise, invoice-fraud, or vendor-impersonation case
• Confirming whether a domain or brand was spoofed against your users

When NOT to Use

• You extracted an attachment and need to detonate it — come here first to safely extract and defang it, then hand the payload to analyzing-malware
• The phish already succeeded and you are chasing the mailbox/OAuth compromise in the tenant — use investigating-m365-entra
• You are building the phishing campaign, not analyzing one — use performing-social-engineering
• The broader incident the phish kicked off — use responding-to-incidents
• Analyzing the callback traffic from a detonated payload — use analyzing-network-traffic

Safe Handling — Do This First

Treat every reported message as live. The failure mode is not misreading a header; it is clicking a link in a production mail client or double-clicking an attachment on your own host.

• Never open the message in a live client. Attacker-controlled remote images fire a read beacon; one click on a link authenticates you to their harvester.
• Work from the raw source only — the .eml/.msg, not a forwarded copy. Forwarding rewrites headers and strips the evidence you need.
• Defang every indicator before it touches a report, ticket, or chat: http → hxxp, . → [.], @ → [at]. So http://evil.com/login becomes hxxp://evil[.]com/login. Defanging prevents an accidental click downstream and stops link-preview bots from detonating it for you.
• Extract and detonate only in an isolated VM with no host sharing and simulated or monitored egress — see analyzing-malware for the build.

Getting the Raw Message

The visible email is a rendering. You need the source with all headers.

• Outlook/Exchange: save as .msg, or in OWA use "View message source".
• Gmail: "Show original" → Download Original gives a .eml.
• .msg → readable: msgconvert sample.msg produces a .eml (RFC822).
• Inspect structure: emldump.py sample.eml lists MIME parts and indices; emldump.py -s 4 -d sample.eml dumps part 4 (an attachment) without opening it. A .msg is an OLE compound file — oledump.py (DidierStevens) lists its streams.
• View full headers: read the top block of the raw file directly, or paste into Message Header Analyzer (MHA) / Google's mha / MXToolbox Header Analyzer for a parsed hop table.

Keep the original file hashed and untouched; work on copies.

The Received Chain

The Received: headers are added by each mail server the message passes through, newest at the top. Read them bottom-up: the bottom-most Received is the originating server — the earliest, least-forgeable hop.

Received: from mail.contoso.com (mail.contoso.com [203.0.113.9])
    by mx.recipient.com ... ; Tue, 21 Jul 2026 09:14:02 +0000   <- final hop
Received: from smtp.sketchy-vps.ru ([185.220.101.5])
    by mail.contoso.com ...   ; Tue, 21 Jul 2026 09:13:58 +0000  <- origin

• Trace the originating IP: the bottom hop's [bracketed IP]. Geolocate and WHOIS it (whois 185.220.101.5), check reputation, and reconcile it against the claimed sender. A "From: ceo@contoso.com" that originates on a Russian VPS is your finding.
• Spot forged hops: attackers prepend fake Received lines to fabricate a reputable origin. Only hops added by servers you trust are reliable — trust breaks at the first server outside your control. A hop that references a server not present in the next hop's by is invented.
• Timezone and hop-time anomalies: hop timestamps should increase upward by seconds. Negative deltas, multi-hour jumps, or a mix of implausible timezones indicate forgery or relay through odd infrastructure.
• Reconcile with the claimed sender: the origin domain, its PTR/rDNS, and the From domain should tell one coherent story. They usually do not in a phish.

Authentication Results

SPF, DKIM, and DMARC are the forgery-resistant checks. The receiving server records them in Authentication-Results. Read it, and re-verify rather than trusting a summary.

Authentication-Results: mx.recipient.com;
  spf=pass (sender IP is 185.220.101.5) smtp.mailfrom=bounce.sketchy-vps.ru;
  dkim=pass header.d=sketchy-vps.ru header.s=selector1;
  dmarc=fail (p=reject sp=reject dis=none) header.from=contoso.com

• SPF authenticates the envelope sender (Return-Path / smtp.mailfrom / MAIL FROM), not the visible From. Values: pass (IP is authorized for the envelope domain), fail (hard -all reject), softfail (~all, suspicious but delivered), neutral/none (no policy). Check the domain's record: dig txt contoso.com and read the v=spf1 ... string.
• DKIM is a cryptographic signature over selected headers and the body. dkim=pass proves the message was signed by the key at d='s selector and not modified. The load-bearing question is alignment: does header.d= match the From domain? A valid signature from d=mailer-xyz.com on a message claiming From: contoso.com is not contoso. Re-verify with dkimverify < sample.eml (dkimpy) and fetch the key via dig txt selector1._domainkey.contoso.com.
• DMARC ties SPF/DKIM to the visible From via alignment and applies the domain owner's policy. dmarc=pass requires SPF or DKIM to pass AND be aligned with header.from. Read the policy: dig txt _dmarc.contoso.com → v=DMARC1; p=reject; .... p=reject/quarantine with dmarc=fail means the owner told you to distrust it.
• ARC (ARC-Seal/ARC-Authentication-Results) preserves upstream auth results across forwarders that would otherwise break SPF/DKIM. Use it to see how auth looked before a mailing list or gateway relayed the message.
• Envelope vs header From: Return-Path/envelope-from is what bounces go to and what SPF checks; the header From: is what the user sees. Phishers make them differ — a benign-looking From with a throwaway envelope domain that happens to pass SPF is the classic pattern.

Display-Name and Lookalike Spoofing

Much phishing passes authentication because it comes from a real mailbox on a lookalike domain. The auth checks pass for that domain; the deception is visual.

• Display-name spoofing: From: "IT Helpdesk" <random@gmail.com>. The name is a free-text label; read the actual address.
• Cousin / lookalike domains: cont0so.com, contoso-support.com, contoso.co. Diff against the real domain character by character.
• Homoglyph / IDN: Unicode characters that render like ASCII (Cyrillic а for Latin a). Punycode-encoded domains appear in headers as xn-- — e.g. xn--cntoso-.... Decode with idn / python3 -c "print('xn--80ak6aa92e.com'.encode().decode('idna'))" and compare the rendered form.
• Reply-To mismatch: From: ceo@contoso.com but Reply-To: ceo.contoso@gmail.com. The reply silently goes to the attacker — a hallmark of BEC.
• BEC with no payload: pure text asking for a wire transfer, gift cards, or W-2 data. No link, no attachment, nothing to sandbox. The signal is entirely in the headers (Reply-To, origin, auth) and the pretext.

Header Forensics

• Message-ID sanity: format is <unique@sending-domain>. The domain should match the sending infrastructure. A Message-ID domain that disagrees with the origin, or a malformed/duplicated ID, suggests a spoofing tool.
• X-Originating-IP: some webmail stamps the true client IP here — pivot on it, but note it is client-suppliable and can be forged.
• X-Mailer / User-Agent: reveals the sending client. Bulk-phish kits and scripts (PHPMailer, Python, custom mailers) look nothing like Outlook or the claimed sender's normal stack.
• Mailer fingerprints: legitimate bulk senders (SendGrid, Amazon SES, Mailchimp) add characteristic X- headers and Received paths. Their presence on a "personal" note from your CEO is a contradiction.