Phishing Analysis: That Email From the CEO Is Definitely Legit

Category: Incident Response

Tags: phishing, email-forensics, incident-response, social-engineering, headers

Every SOC analyst has a queue full of "is this phishing?" tickets. The answer is almost always yes. The interesting question is not whether the email is malicious -- it is whether it is part of a broader campaign, whether credentials were compromised, and whether the same lure has landed in fifty other inboxes while everyone debates whether to click the "report phishing" button.

This article covers the practical workflow for phishing analysis -- from email header examination through URL investigation and attachment sandboxing, including the fine art of tracing phishing kits back to their operators. Because the only thing better than blocking a phishing email is understanding who sent it, how, and what they were after.

The Phishing Landscape

Not all phishing is created equal. The sophistication ranges from "Nigerian prince" to "indistinguishable from internal IT communications."

BEC alone accounts for billions in annual losses, and it rarely involves malware at all -- just a convincingly worded email and a finance department that processes wire transfers before coffee.

Email Header Analysis

Headers are the forensic goldmine of phishing analysis. The email body is what the attacker wants the recipient to see; the headers reveal what actually happened.

Key Headers

Reading the Received Chain

The Received headers trace the email's journey from origin to destination. Read them bottom to top -- the bottom-most header is the originating server, each subsequent header is a relay.

Received: from mail-relay.attacker.com (203.0.113.50)
    by mx.victim.com with ESMTP; Thu, 15 Jan 2024 14:30:00 +0000
Received: from localhost (127.0.0.1)
    by mail-relay.attacker.com; Thu, 15 Jan 2024 14:29:58 +0000

Look for discrepancies: a "From" address claiming to be internal-it@company.com originating from a server in a country where the company has no operations is not subtle.

SPF, DKIM, and DMARC

These three authentication mechanisms are the frontline defence against email spoofing -- and understanding their results is essential.

A DMARC failure with p=none means the domain owner has not enforced a reject policy -- the email arrives regardless. A depressing number of organisations run DMARC in monitoring mode indefinitely, which is rather like installing a burglar alarm and never connecting it to anything.

URL Analysis

Most credential harvesting phishing directs victims to a fake login page. Analysing the URL without clicking it is essential.

Safe Analysis Tools

What to Check

• Domain age -- phishing domains are typically registered hours or days before use. A "Microsoft password reset" page on a domain registered yesterday is not Microsoft.
• SSL certificate -- free Let's Encrypt certificates on suspicious domains. The padlock means encryption, not legitimacy.
• Redirect chains -- URL shorteners or multiple redirects before the final phishing page.
• Resource hashes -- in URLScan.io, note the hashes of background images and JavaScript files. Search for other sites using the same resource hash to map campaign infrastructure.
• Page content -- does the fake login page POST credentials to a different domain? Check the form action attribute.

Defanging URLs

When sharing indicators, defang URLs to prevent accidental clicks:

hxxps://login-microsoftonline[.]evil[.]com/auth/

Replace http with hxxp and wrap dots in brackets. Every SOC analyst who has accidentally clicked a live phishing URL in a report understands why this convention exists.

Attachment Analysis

Phishing attachments range from Office documents with macros to HTML files that render credential harvesting pages locally.

Common Malicious Attachment Types

Sandboxing Attachments

Never open suspicious attachments on a production system. Use:

• Any.Run -- interactive cloud sandbox with real-time observation
• Hybrid Analysis -- automated analysis with CrowdStrike backing
• Joe Sandbox -- detailed behavioural reports
• VirusTotal -- multi-engine scanning (remember: uploads are searchable by everyone)

For sensitive samples from client engagements, use a private sandbox instance. What goes into VirusTotal stays in VirusTotal -- and the threat actor can search for their own sample to determine whether the target has detected it.

Phishing Kit Analysis

Phishing kits -- the packaged toolkits that attackers deploy on compromised web servers -- often reveal more about the operation than the phishing email itself.

Common Kit Structure

/office365/           Resource files (JS, images, CSS)
/data.txt             Visitor log -- IP, user-agent, country, timestamp
/email.php            Exfiltration email address
/send.php             Credential submission handler
/readme.txt           Kit documentation and author handle
/antibot.php          Researcher/bot blocking

What to Extract

• Exfiltration email from email.php or send.php -- this is where stolen credentials are sent
• Secondary exfiltration -- some kits POST data to external validation servers before emailing
• Author attribution -- readme files, code comments, and variable naming conventions
• Anti-analysis features -- IP blocking, user-agent filtering, geofencing
• Redirect URL -- where victims land after entering credentials (usually the real login page, to reduce suspicion)

Campaign Mapping

Resource hash pivoting in URLScan.io is remarkably effective for mapping phishing campaigns:

1. Scan a known phishing URL
2. Note the SHA256 hashes of background images and JavaScript files
3. Search URLScan for other pages using the same resource hashes
4. Build a map of the campaign's infrastructure -- often dozens of domains using identical kits

---

O365 / M365 Investigation

When credentials have been compromised via phishing, the Unified Audit Log (UAL) reveals what the attacker did next.

Key UAL Operations

Operation	Indicates
MailboxLogin	Account access -- check IP and user-agent
MoveToDeletedItems	Attacker deleting the original phishing email
New-InboxRule	Mail forwarding rule -- exfiltrating future emails
Set-Mailbox	Mailbox configuration change
SendAs	Sending emails as the compromised user
SearchQueryInitiated	Searching the mailbox for sensitive data

The Classic BEC Sequence

1. Credential harvesting email arrives
2. Victim enters credentials on fake login page
3. Attacker logs in from a foreign IP
4. Attacker immediately deletes the phishing email from the inbox
5. Attacker creates an inbox rule to forward or hide future emails
6. Attacker sends BEC emails to finance or HR
7. Meanwhile, the victim has no idea anything happened

Finding the deleted phishing email: look for MoveToDeletedItems events within minutes of the first unauthorised MailboxLogin from a suspicious IP.

---

Encoded PowerShell in Phishing

Phishing emails that deliver malware increasingly use PowerShell download cradles -- often heavily obfuscated.

Quick Decode Pipeline

# Step 1: Extract the base64 payload
cat payload.txt | grep -oE '[a-zA-Z0-9/+=]{40,}' | base64 -d

# Step 2: Convert from UTF-16LE to UTF-8 (Microsoft's encoding)
| iconv -f utf16 -t utf8

# Step 3: Extract inner encoding and decompress
| grep -oE '[a-zA-Z0-9/+=]{40,}' | base64 -d | gunzip

Or use CyberChef with the recipe: From Base64 -> Decode Text (UTF-16LE) -> Regular Expression (extract base64) -> From Base64 -> Gunzip.

---

Phishing Response Playbook

A structured response ensures nothing gets missed in the scramble to contain a phishing incident.

1. Identify -- confirm the phishing email and extract indicators (sender IP, URLs, attachment hashes)
2. Scope -- search the mail gateway for all recipients of the same message (Message-ID, subject, sender)
3. Contain -- purge the email from all mailboxes, block sender domain, block phishing URLs at the proxy
4. Assess -- determine who clicked, who entered credentials, who opened attachments
5. Remediate -- reset passwords for compromised accounts, revoke active sessions, check for inbox rules
6. Hunt -- search for UAL activity from suspicious IPs, check for lateral movement
7. Report -- document indicators, update block lists, submit phishing URLs to PhishTank and Google Safe Browsing

The most commonly skipped step is number 6. Resetting a password without checking whether the attacker has already established persistence (inbox rules, OAuth app registrations, MFA device additions) means the attacker simply logs back in through the side door.

---

What's Next in the Series

• Incident Response 101: PICERL -- the framework that gives this playbook structure
• Incident Response 102: Evidence Preservation -- preserving email evidence properly
• Malware Analysis 101: The Workflow -- when the attachment turns out to be interesting
• Network Forensics -- trace C2 traffic after initial compromise