Phishing Analysis: A Blue Team Guide to Email Threat Investigation

This post covers the full analysis workflow, how email works, types of phishing, collecting artifacts, analyzing them with tools, and taking defensive action.

---

The 6-Step Phishing Investigation Walk-Through

Most SOC interviews open with: "Walk me through investigating a phishing alert." Memorizing tool features doesn't help here. What helps is a memorized investigation skeleton you can speak out loud while thinking.

Here's the skeleton, in order, that turns a noisy phishing inbox into a defensible decision:

1. Triage: pull the alert. What's the source (SEG, user report, EDR)? What confidence level? Who reported it, and when? The alert with no human context is usually a false positive.

2. Email examination: headers first. SPF/DKIM/DMARC pass? Mail-from vs return-path mismatch? Received-from chain shows unexpected hops? Then body: language patterns, suspicious links, urgency tells.

3. Payload analysis: if there's an attachment or link, sandbox it (don't run it on your endpoint). Hash the file, check VirusTotal + URLscan + AbuseIPDB. Capture network behavior in detonation.

4. Scope: how many users got the same email? Same sender? Same payload hash? Same campaign indicators? Pivot in SIEM by sender domain, hash, URL, attached file name. The single phishing email is rarely alone.

5. Contain & document: quarantine if confirmed malicious. Notify affected users. Block IOCs at the email gateway and proxy. Document the timeline, the IOCs, the affected accounts. Every analyst's investigation should leave a paper trail another analyst could pick up cold.

6. Communicate: brief the team in a clear summary: what happened, who's affected, what's contained, what's still being watched. Tier 1 ends here, with the right escalation path to Tier 2 if the campaign is sophisticated.

The rest of this post breaks down the technical detail behind each step.

---

How Email Works

Before analyzing phishing, need to understand the protocols behind it.

• SMTP (Simple Mail Transfer Protocol), sends emails. TCP port 587 (TLS) or legacy port 25.

• POP3 (Post Office Protocol), downloads email to local client and deletes from server.

• IMAP (Internet Message Access Protocol), keeps email on server, accessible from any device.

Email Delivery Flow

Sender's client → Outbound SMTP server → DNS lookup (recipient domain) 
→ Route through internet → Recipient SMTP server → Recipient client (POP3/IMAP)

The key takeaway: email passes through multiple servers. Each server adds headers. These headers are what we analyze.

---

Types of Phishing

---

Tactics Attackers Use

• Impersonation: pretend to be a trusted entity (colleague, vendor, IT support)

• Sender Spoofing: forge the "From" address to look legitimate

• Typosquatting: register look-alike domains (e.g., amaz0n.com, rnicrosoft.com)

• Homograph Attacks: use unicode characters that look identical (e.g., Cyrillic "а" vs Latin "a")

• HTML Styling: hide the real URL behind styled buttons

• URL Shortening: obscure destination using bit.ly, tinyurl

• Legitimate Service Abuse: host payloads on Google Docs, Dropbox, OneDrive

---

Collecting Artifacts

This is the core of phishing analysis. Collect everything before blocking anything.

Email Artifacts

• Sending address: display name vs. actual address (often different)

• Reply-to address: critical indicator. Attackers often set a different reply-to to bypass sender verification.

• Date and time: track campaign trends

• Originating IP: check X-Sender-IP or X-Originating-IP in headers

• Subject line: useful for finding similar phishing emails across mailboxes

• Recipients: check BCC field for hidden recipients (mass campaign indicator)

Web Artifacts

• Full URLs: copy via right-click "Copy Link Destination". Never click. Never hand-type.

• Root domain: determine if it's a malicious domain or a compromised legitimate site

• Redirect chains: follow 302 hops through multiple domains to find the actual phishing page

File Artifacts

• Attachment filename + extension: for EDR blocking rules

• SHA256 hash: standard for VirusTotal lookups. Avoid MD5/SHA1 (hash collision vulnerabilities).

---

How to Extract Email Headers

Open the .eml file in a text editor (Sublime Text works well).

Use CTRL+F to search for:

• From, sender email address

• To, recipient

• Subject, subject line

• Date, timestamp

• X-Sender-IP or X-Originating-IP, originating IP

• Reply-To, reply address (if different from sender, suspicious)

• Content-Transfer-Encoding, check for Base64 encoded content

Here's an example, opening a phishing email in Sublime Text and searching for the originating IP:

Reverse DNS Lookup

Once you have the sending server IP, verify it with a WHOIS lookup:

• MXToolbox: https://mxtoolbox.com/ReverseLookup.aspx

• Compare the resolved hostname against the claimed sender domain

• If it doesn't match, likely spoofed

Decoding Base64 Content

Some phishing emails encode their body in Base64 to bypass filters.

• Open CyberChef (https://gchq.github.io/CyberChef/)

• Paste the encoded content

• Apply "From Base64" recipe

• This reveals hidden URLs, embedded images, and actual email content

---

Analysis Tools

Investigation Workflow

1. Extract all artifacts from the email

2. Check sender IP with Reverse DNS

3. Screenshot any URLs with URL2PNG or URLScan.io

4. Check URLs against VirusTotal, URLhaus, PhishTank

5. If attachments exist, get SHA256 hash, check VirusTotal, detonate in sandbox

6. Check domain registration date (WHOIS), newly registered domains are suspicious

7. Document everything

---

Real Investigation: Following a Redirect Chain

Phishing emails often use multiple redirects to hide the actual destination. Here's a walkthrough from a real investigation.

The Setup

A phishing email impersonating Disney+ was targeting German users. The email contained a link, but the link didn't go directly to the phishing site.

First, copy the link (right-click, never click) and decode it:

Following the Redirects

The first URL returns an HTTP 302 Found, a redirect:

Check the HTTP header to find where it's redirecting to:

After following the full redirect chain, we reach the actual phishing domain:

Analyzing the Credential Harvester

The phishing page contained JavaScript that collected user credentials. Investigating the JS revealed what data was being harvested:

The stolen data was POST'ed to a specific endpoint:

WHOIS and Infrastructure Analysis

Checking the WHOIS record, the domain was registered just 2 days before the phishing email was sent:

The hosting server was located in Russia:

And the same server was hosting 10+ other credential harvesters, all targeting banks:

Key Takeaways from This Investigation

• One phishing email led to a full infrastructure of credential harvesters

• Redirect chains are used to evade URL reputation checks

• WHOIS registration date is a strong indicator, freshly registered domains targeting your org are suspicious

• Always investigate the hosting infrastructure, you might find more campaigns

---

Defensive Actions

Preventative

SPF (Sender Policy Framework)

• DNS TXT record that defines which servers can send emails for your domain

• Syntax: v=spf1 a: include:mailgun.org protection.outlook.com -all

• -all = hard fail, block unauthorized senders

DKIM (DomainKeys Identified Mail)

• Cryptographic signature to verify email authenticity

• Sender's mail server generates an encrypted hash (private key) → added to email header

• Recipient server verifies with public key stored in DNS

• Syntax: V=DKIM1 <key type> <public key>

DMARC (Domain-based Message Authentication, Reporting & Conformance)

• Builds on SPF + DKIM. Lets domain owners set policy for failed authentication:

  • p=none, monitoring only

  • p=quarantine, send to spam

  • p=reject, block completely

• Example: v=DMARC1; p=quarantine; rua=mailto:admin@company.com

• Generates reports for monitoring authentication failures

Other Preventative Measures:

• Spam filters (content and reputation-based)

• Attachment sandboxing, detonate before delivery

• External email banners, warn users about external senders

• Security awareness training

Reactive

When a phishing email is confirmed:

1. Quarantine: remove from all mailboxes that received it

2. Notify: alert affected users immediately

3. Block sender: add sending address/domain to mail gateway blocklist

4. Block URLs: add malicious URLs/domains to proxy or firewall blocklists

5. Block file hashes: add to EDR/antivirus blocklists

6. Reset credentials: if any user clicked and submitted credentials

Sanitizing Artifacts for Reports

Before sharing IOCs in reports or tickets, defang them to prevent accidental clicks:

• URLs: hXXps://malicious[.]com/phish

• IPs: 192.168.1[.]1

• Emails: attacker[@]evil[.]com

---

Phishing Report Template

A proper phishing analysis report should include:

1. Email Header Info: sender, recipient, date, originating IP, subject

2. Artifacts & Body Content: URLs, attachments, embedded content with sanitized IOCs

3. Analysis Process & Results: which tools were used, what they found

4. Classification: recon, credential harvester, malware delivery, BEC

5. Defensive Measures Taken: what was blocked, who was notified

6. Attached Evidence: original .eml or .msg file, screenshots

---

Key Takeaways

• Always collect artifacts before blocking, you need the evidence

• Reply-To address is one of the most reliable phishing indicators

• Use SHA256 for file hash lookups (not MD5/SHA1)

• Never click links directly, use right-click "Copy Link Destination" or extract from text editor

• SPF + DKIM + DMARC together provide layered email authentication

• Sanitize all IOCs before sharing in reports

• Check domain WHOIS, newly registered domains targeting your org is a strong indicator

• Investigate the infrastructure, one phishing domain often hosts many campaigns