Phishing Analysis: A Step-by-Step Methodology for Security Teams

Phishing remains the most common initial access vector in security incidents worldwide. Despite billions spent on email gateways, user awareness training, and domain authentication protocols, a steady stream of malicious emails continues to land in employee inboxes. When they do, your security team needs a consistent, repeatable methodology for analyzing them — not just to neutralize the immediate threat, but to extract every piece of intelligence the attacker has inadvertently given you.

This guide presents a six-step phishing analysis methodology that takes you from raw email through header analysis, URL investigation, attachment detonation, IOC extraction, and response actions. Whether you're a SOC analyst triaging your tenth reported phish of the day or an incident responder investigating a targeted campaign, this framework ensures you don't miss critical findings.

Why Phishing Analysis Matters

It's tempting to treat phishing as a binary problem: block the email, delete it, move on. But every phishing email that reaches your users carries intelligence about the threat actor's infrastructure, targeting preferences, and operational patterns. Proper analysis extracts that intelligence and feeds it back into your defenses.

A single well-analyzed phishing email can yield: sender infrastructure (IPs, domains, mail servers), credential harvesting pages or malware delivery URLs, payload samples with behavioral indicators, indicators of compromise that can be deployed across your security stack, and patterns that connect the email to broader campaigns targeting your industry.

Skip the analysis, and you block one email. Do it properly, and you block every future email from that campaign — and potentially share intelligence that protects other organizations too.

Setting Up Your Analysis Environment

Before you touch a suspicious email, you need a safe environment. Phishing analysis should never be performed on a production workstation. A single misclick — opening an attachment, following a URL — can compromise the analyst's system and give the attacker a foothold inside your security team.

Essential Environment Components

• Isolated analysis VM — A dedicated virtual machine (REMnux, FlareVM, or a hardened Linux distribution) that is network-isolated or routes traffic through a VPN. Snapshot before each analysis session so you can revert cleanly.
• Email client for raw viewing — An email client or text editor that lets you view the full raw message source including all headers. Thunderbird, mutt, or simply a text editor with the .eml file works well.
• URL analysis tools — urlscan.io for safe URL screenshots and analysis, VirusTotal for URL reputation, and a browser inside your isolated VM for manual inspection when necessary.
• File analysis sandbox — ANY.RUN, Joe Sandbox, or a local Cuckoo Sandbox instance for detonating attachments and observing behavioral indicators.
• Header analysis tools — MXToolbox Header Analyzer, Google Admin Toolbox, or command-line tools for parsing and visualizing email routing paths.

Critical safety rule: Never open attachments or click links from suspicious emails on a production system, your corporate network, or any machine with access to sensitive resources. Even "just looking" at a URL in a browser can trigger drive-by downloads, browser exploits, or attacker-side logging that confirms your email address is active.

Step 1: Email Header Analysis

Email headers are the metadata envelope of every message. They reveal the actual path the email took through the internet, the authentication status of the sender, and often expose inconsistencies that confirm the email is malicious. Headers are the single most information-rich artifact in phishing analysis.

Key Headers to Examine

• From vs. Return-Path — The From header is what the user sees and is trivially spoofable. The Return-Path (also called Envelope-From) indicates where bounce messages are sent. A mismatch between these two is an immediate red flag. Example: From: [email protected] with Return-Path: [email protected].
• Received headers — Read these bottom-to-top. Each mail server that handled the message adds a Received header at the top. The bottom-most Received header is closest to the originating server. Trace the email's actual path and note any suspicious hops, unexpected countries, or consumer-grade email services sending on behalf of a corporate domain.
• Authentication-Results — This header shows whether the email passed SPF, DKIM, and DMARC checks. A legitimate email from a major brand should pass all three. Failures or missing results indicate the email was not sent from the domain's authorized infrastructure.
  • SPF — Did the sending IP match the domain's authorized senders?
  • DKIM — Was the email's cryptographic signature valid?
  • DMARC — Did the email pass the domain owner's alignment policy?
• X-Originating-IP — When present, reveals the IP address of the client that submitted the email. Check this against threat intelligence feeds and geolocation databases.
• Message-ID — The unique identifier for the message. The domain portion should match the sending organization. A Message-ID from @gmail.com on an email claiming to be from your bank is suspicious.
• Reply-To — If different from the From address, this is a classic indicator of phishing. The attacker wants replies to go to an address they control, not the spoofed sender.

Reading Received Headers

Received headers are the most complex but most valuable. Read them from bottom to top to trace the email's journey. Each header includes a timestamp and typically identifies both the sending and receiving server. Look for:

• Unusual originating servers (consumer ISPs, cloud hosting providers, residential IPs)
• Geographic inconsistencies (an email from a European company routing through Southeast Asian servers)
• Timestamp anomalies (headers with timestamps that don't flow chronologically)
• Forged headers (headers that the attacker inserted to make the email appear more legitimate)

Step 2: Body and Social Engineering Analysis

After the headers, examine the email body for social engineering indicators. Document the pretext — the story the attacker is using to manipulate the recipient — as this is valuable for user awareness training and campaign correlation.

• Urgency and pressure tactics — "Your account will be suspended in 24 hours," "Immediate action required," "Failure to respond will result in legal action." Legitimate organizations rarely demand immediate action via email.
• Authority impersonation — Is the email pretending to be from the CEO, IT department, HR, or a trusted vendor? Check whether the display name matches the actual sending address.
• Brand spoofing indicators — Look for copied logos, brand colors, and formatting that mimics legitimate communications. Compare against actual emails from the impersonated organization. Look for subtle differences: slightly wrong colors, outdated logos, broken formatting.
• Language anomalies — Grammatical errors, unusual phrasing, inconsistent tone, or mixed language conventions (British English in an email supposedly from an American company) can indicate the email was written by a non-native speaker or generated by a translation tool.
• Display name spoofing vs. domain spoofing — These are different attack techniques. Display name spoofing uses a legitimate-looking name with an attacker-controlled email address (e.g., "John Smith CEO" <[email protected]>). Domain spoofing forges the actual email domain. The distinction matters for your response — domain spoofing indicates potential DMARC configuration issues.

Step 3: URL Analysis

Extract every URL from the email body, including URLs embedded in images and hyperlinked text where the display text differs from the actual URL. This discrepancy — display text showing https://your-bank.com while the actual link points to https://your-bank-login.malicious.com — is one of the most common phishing techniques.

URL Investigation Process

1. Domain registration check — Use WHOIS data to check when the domain was registered. Phishing domains are frequently registered within days or hours of the campaign launch. A domain registered less than 30 days ago impersonating a major brand is almost certainly malicious.
2. URL structure analysis — Look for typosquatting (e.g., micros0ft.com, gooogle.com), subdomain abuse (e.g., login.microsoft.com.attacker.com), and path manipulation that makes the URL appear legitimate at first glance.
3. Redirect chain analysis — Many phishing URLs use multiple redirects to evade email gateway scanning. The initial URL might point to a legitimate service (Google AMP, Cloudflare Workers, Azure blob storage) that redirects to the actual phishing page. Follow the full redirect chain in your sandbox environment.
4. Destination content analysis — Use urlscan.io to capture a screenshot and DOM content of the destination page without visiting it directly. Check for credential harvesting forms, fake login pages, or malware download prompts.
5. Reputation checks — Submit the URL to VirusTotal, Google Safe Browsing, and PhishTank. Note that brand-new phishing URLs often have zero detections — a clean result does not mean the URL is safe.
6. URL shortener resolution — If the email uses URL shorteners (bit.ly, tinyurl.com, etc.), resolve them to the full destination URL before analysis. Most URL analysis tools can do this automatically.

Step 4: Attachment Analysis

If the phishing email includes attachments, treat every attached file as potentially malicious. Even seemingly innocent file types can contain embedded macros, exploits, or scripts.

Static Analysis

1. File type validation — Verify that the file extension matches the actual file type. Attackers frequently rename executables with document extensions (e.g., invoice.pdf.exe) or use double extensions. Check the MIME type and file magic bytes with the file command.
2. Hash generation — Generate MD5 and SHA256 hashes of the file. These are your primary IOCs for the attachment and allow you to check for prior sightings.
3. VirusTotal lookup — Submit the hash (not the file, unless your organization's policy permits it) to VirusTotal. Check detection ratios and any behavioral analysis results from previous submissions.
4. String analysis — Run strings against the file to extract human-readable text. Look for URLs, IP addresses, registry keys, file paths, and suspicious API calls. For Office documents, use tools like olevba to extract and analyze VBA macros.
5. Metadata extraction — Extract document metadata (author, creation date, modification history) with exiftool or similar tools. Metadata can reveal the attacker's environment or connect the document to other samples in the same campaign.

Dynamic Analysis

Detonate the attachment in a sandbox environment and observe its behavior:

• Process activity — Does the document spawn child processes? Office documents launching cmd.exe, powershell.exe, or wscript.exe is a strong malicious indicator.
• Network callbacks — Does the file reach out to external URLs or IP addresses? Capture all network traffic during detonation to identify C2 infrastructure.
• File system changes — Does the file write additional files to disk? Dropped payloads, scripts, or configuration files are critical artifacts.
• Registry modifications — Does the file create persistence mechanisms through registry changes?

Common attachment lures to watch for: invoice PDFs with embedded JavaScript, delivery notification documents with macros, shared document links that download malware, password-protected ZIP files (the password is in the email body to bypass gateway scanning), and HTML attachments that render credential harvesting forms locally.

Step 5: IOC Extraction

By this point in the analysis, you've accumulated a significant body of indicators. The next step is to compile, categorize, and format them for deployment across your security infrastructure.

IOC Categories

• Email indicators — Sender addresses, Reply-To addresses, email subjects, display names, Message-IDs
• Network indicators — Domains, URLs, IP addresses (originating IPs, C2 IPs, hosting IPs)
• File indicators — File hashes (MD5, SHA256), file names, file sizes, MIME types
• Behavioral indicators — Process execution chains, registry modifications, network communication patterns

Confidence Levels

Not all IOCs are created equal. Assign confidence levels based on your analysis:

• High confidence — Directly observed and confirmed malicious. Example: the SHA256 hash of a confirmed malware sample, the URL of a credential harvesting page you analyzed.
• Medium confidence — Associated with the malicious activity but not independently confirmed malicious. Example: the IP address of the mail server that relayed the phishing email (it could be a compromised legitimate server).
• Low confidence — Loosely associated or potentially shared infrastructure. Example: a hosting provider IP that many legitimate sites also use.

Format IOCs for your threat intelligence platform (MISP, OpenCTI, ThreatConnect) and ensure they include context: the campaign they're associated with, the confidence level, the date of observation, and a reference to your analysis report.

Step 6: Response Actions

Analysis without action is wasted effort. Once you've completed the analysis and extracted IOCs, execute your response workflow:

1. Block IOCs at the email gateway — Add sender addresses, sender domains, and attachment hashes to your email security platform's block list. Create transport rules to quarantine emails matching the identified subject lines or header patterns.
2. Block network IOCs — Add malicious domains and IPs to your firewall, proxy, and DNS filtering rules. If you use a threat intelligence platform that feeds your security stack, push IOCs through the automated pipeline.
3. Search mail logs for related messages — Query your email logs for other messages from the same sender, same domain, or same subject line pattern. Identify how many recipients received the phishing email and whether the campaign is ongoing.
4. Identify impacted users — Determine which users received the email, who opened it, who clicked links, and who submitted credentials or opened attachments. Each category requires a different response level.
5. Credential resets — For users who submitted credentials on a phishing page, initiate immediate password resets and review their accounts for signs of unauthorized access. Check for new forwarding rules, delegated access, or MFA changes.
6. Update detection rules — Create or update SIEM and EDR detection rules based on the behavioral indicators from your analysis. If the phishing delivered malware, ensure your detections cover the full execution chain, not just the initial payload hash.
7. Share intelligence — Report IOCs to relevant ISACs (Information Sharing and Analysis Centers), share with trusted industry peers, and submit phishing URLs to platforms like PhishTank for community benefit.

Automation Opportunities

Manual phishing analysis doesn't scale. If your SOC handles more than a handful of reported phishing emails per day, you need automation to maintain quality without burning out your analysts.

• SOAR playbooks for initial triage — Automatically extract headers, URLs, and attachment hashes from reported emails. Run reputation checks against VirusTotal, urlscan.io, and your threat intelligence feeds. Score the email and route it: obvious spam goes to auto-close, confirmed malicious goes to blocking, ambiguous cases go to an analyst for manual review.
• Automated header analysis — Parse authentication results, originating IPs, and routing paths automatically. Flag discrepancies between From and Return-Path, failed SPF/DKIM/DMARC, and newly registered sender domains.
• Sandbox detonation APIs — Submit attachments to sandbox APIs (ANY.RUN, Joe Sandbox, VirusTotal) programmatically and ingest the behavioral results into your analysis workflow.
• Auto-IOC extraction — Use tools like ioc-finder or MISP modules to automatically extract and format IOCs from analysis reports.
• Reporter feedback loops — Automatically notify the user who reported the phishing email about the outcome. Positive feedback reinforces reporting behavior and keeps users engaged with your phishing awareness program.

Start simple. Even automating the header extraction and initial reputation checks saves analysts significant time per reported email. Build complexity incrementally as your workflow matures.