How to Analyze a Phishing Email: SOC Walkthrough

Phishing email analysis is the SOC workflow for deciding whether a reported message is malicious, scoping how far it spread, and producing a defensible verdict with extracted indicators. It runs in a fixed order: handle the message safely, read the headers for authentication and routing tells, triage the URLs and attachments in isolation, reach a verdict, then write the ticket. Each step has a specific evidence source and a specific decision it feeds.

This walkthrough takes that sequence one step at a time using a realistic user-reported email, so the next time a "this felt off" forward lands in your queue you have a repeatable process rather than an improvised one.

Before you touch anything: the 30-second rules

• Never open a suspicious attachment or click a link directly — always work in a sandboxed or isolated environment first.
• The email header is your primary evidence source: read the Received chain, SPF/DKIM/DMARC results, and any From vs. Reply-To mismatch before you look at the body.
• Defang every IOC before pasting it anywhere. Replace dots with [.] and https:// with hxxps://.
• A verdict without documentation is just an opinion. The ticket must state the verdict up front, list every IOC defanged, and record every action taken.
• Scope the campaign before you close the alert: a SIEM sweep of the sending IP and domain reveals whether others received the same lure.

Step 1: Safe Handling Before You Touch Anything

The most dangerous moment in a phishing investigation is the first thirty seconds. Before you scroll, click, or copy anything from the reported email, establish your working environment.

The CISA Phishing Guidance recommends treating every user-reported phish as genuine until your analysis proves otherwise. That posture starts with isolation. If your organisation uses a purpose-built phishing analysis platform such as PhishTool or Sublime Security, route the reported message through that system rather than your standard mail client. These tools render the email in a read-only sandbox, extract headers automatically, and flag suspicious patterns before your eyes ever land on the body.

If you do not have a dedicated tool, at minimum forward the raw message (including full headers) to a fresh browser-based analysis session, or export the .eml file and open it in a text editor. The objective is the same: read the evidence without triggering any payload.

Step 2: Header Analysis — Where the Real Story Lives

Email headers are the forensic chain of custody for every message on the internet. They record every server the message passed through, every authentication check that ran, and every result that came back. Most phishing emails fail here long before you look at the body.

Reading a Realistic Phishing Header

Below is a representative fictional header from the scenario described above. The sender appears to be hr-team@globalcorpinc[.]com but the message did not originate there.

Delivered-To: lreyes@yourcompany[.]com
Received: by 10.82.44.116 with SMTP id j4csp2189327obi;
        Tue, 10 Jun 2026 09:12:04 -0700 (PDT)
Received: from mail-send[.]phish-infra[.]net (mail-send[.]phish-infra[.]net [198.51.100.47])
        by mx.yourcompany[.]com with ESMTP id x11si1049321pfo.228;
        Tue, 10 Jun 2026 09:11:58 -0700 (PDT)
Authentication-Results: mx.yourcompany[.]com;
       dkim=fail (signature not verified) header.i=@globalcorpinc[.]com;
       spf=fail (198.51.100.47 is not in the SPF record for globalcorpinc[.]com)
              smtp.mailfrom=noreply@globalcorpinc[.]com;
       dmarc=fail (p=REJECT) header.from=globalcorpinc[.]com
Message-ID: <20260610161158.8744.noreply@globalcorpinc[.]com>
Date: Tue, 10 Jun 2026 09:11:52 -0700
From: "HR Team" <hr-team@globalcorpinc[.]com>
Reply-To: reply-here@fastmail-svc[.]xyz
Return-Path: <noreply@globalcorpinc[.]com>
To: lreyes@yourcompany[.]com
Subject: ACTION REQUIRED: Update Your Direct Deposit Information
X-Mailer: PHPMailer 6.6.4 (https://github.com/PHPMailer/PHPMailer)

Walk through each section from the bottom of the header upward. Headers are appended in chronological order as the message travels, so the most recent hop is at the top and the originating server is near the bottom.

The Received chain shows the physical path. This message arrived from 198.51.100.47, which resolves to mail-send[.]phish-infra[.]net. That hostname has no legitimate relationship to globalcorpinc[.]com. If you run a reverse DNS lookup and a WHOIS query on that IP, you will likely find a bulletproof hosting provider or a recently registered domain with no corporate history.

The Authentication-Results block is often the fastest verdict. Three failures in one block (SPF fail, DKIM fail, DMARC fail with policy of REJECT) means the legitimate owner of globalcorpinc[.]com has explicitly told the internet "do not trust messages we did not sign." This email was not sent by that company.

The From vs. Reply-To mismatch is a social engineering tell. The visible From display name reads "HR Team" and the address looks like globalcorpinc[.]com, which reassures a recipient who does not inspect headers. The Reply-To however points to fastmail-svc[.]xyz, a completely different domain. Any reply from the victim goes to the attacker, not HR.

The X-Mailer header reveals PHPMailer 6.6.4. Legitimate corporate email rarely uses an open-source PHP library for bulk mail. This is consistent with a phishing kit running on a compromised or rented server.

For header parsing at scale, MXToolbox's Email Header Analyzer and Google Admin Toolbox's Messageheader tool can visualise the Received chain and flag authentication failures interactively.

Step 3: URL and Attachment Analysis

Once you have the header picture, you move to the message body. The goal is still zero execution: you want to understand what the attacker intended without triggering any payload.

Defanging IOCs

Before you copy any URL or domain from the email, defang it. Defanging is the standard practice of modifying indicators of compromise so they cannot be accidentally activated when pasted into a ticket, a Slack message, or a threat-intel query.

The two most common transformations are replacing the dot separator in a domain or IP address with [.], and replacing the URL scheme so https:// becomes hxxps://. The body of this fictional email contained the following call-to-action link after defanging:

hxxps://direct-deposit-update[.]globalcorpinc-hr[.]workers[.]dev/portal?token=eyJ0...

Several things stand out immediately. The legitimate domain globalcorpinc[.]com does not appear as the registrable domain here. Instead, globalcorpinc-hr[.]workers[.]dev is a subdomain on Cloudflare Workers, a legitimate hosting platform that attackers frequently abuse because it provides HTTPS by default and bypasses many domain-age reputation checks. The token=eyJ0... parameter is a base64-encoded string, consistent with a phishing kit that tracks individual victims and pre-fills their credentials on the harvest page.

Running Reputation Checks

With the URL defanged, submit it to reputation services. VirusTotal aggregates dozens of antivirus and URL scanners. URLScan.io takes a screenshot of the page, maps its redirects, and records the network requests it makes, all without you ever loading it in your browser.

For a file attachment, the first step is hashing it before opening it. A quick SHA-256 hash on the command line keeps your hands away from the file content:

# Linux / macOS
sha256sum "Direct_Deposit_Update_Form.docm"
 
# Windows PowerShell
Get-FileHash "Direct_Deposit_Update_Form.docm" -Algorithm SHA256

Submit that hash to VirusTotal. If the hash is already known (which is common for commodity phishing kits), you get a detection verdict without ever executing the file. If the hash is unknown, you face a choice: escalate to a senior analyst, submit the file to a sandboxed detonation environment such as Any.run or Cuckoo Sandbox, or treat it as malicious and respond accordingly based on context. For a .docm file (macro-enabled Word document) arriving via an email that already failed all three authentication checks, the contextual threshold to treat it as malicious without further detonation is quite low.

The header never lies. The attacker controls the body, the subject line, and the display name. They cannot control what the receiving mail server writes into the Authentication-Results block.

SIEM Correlation

Before you close the investigation down to this one email, pivot to your SIEM. Search for the sending IP (198.51.100.47), the malicious domain (globalcorpinc-hr[.]workers[.]dev), the Message-ID domain, and the Reply-To address across all inboxes for the past 48 hours.

index=email_gateway
  (src_ip="198.51.100.47" OR subject="ACTION REQUIRED: Update Your Direct Deposit Information"
   OR recipient_domain_in_return_path="globalcorpinc[.]com" OR x_mailer="PHPMailer*")
| stats count by recipient, subject, src_ip, dkim_result, spf_result
| sort -count

A single reported phish is often the tip of a broader campaign. If ten more recipients received the same message and nobody else reported it, your remediation scope just expanded significantly. The SANS Internet Storm Center publishes daily handler diaries on active phishing campaigns that can help you determine whether a given sending infrastructure is part of a known operation.

Step 4: Verdict and Response

With your analysis complete, you have enough evidence to render a verdict and act on it.

In this scenario, the verdict is malicious, confirmed phishing based on: three-way authentication failure (SPF/DKIM/DMARC all fail), sending infrastructure completely unrelated to the claimed sender, a Reply-To address on an unrelated domain registered two weeks prior, and a URL structure consistent with a credential-harvesting kit hosted on Cloudflare Workers.

Your response has three parallel tracks.

Contain: Work with your email administrator to purge the message from every inbox it reached. In Microsoft 365 environments, Content Search and Purge or the Threat Explorer in Defender for Office 365 can do this across the tenant. In Google Workspace, the Admin console message audit log provides the same capability. Simultaneously, submit the sending IP and the malicious domain to your email gateway and firewall for blocking.

Communicate with the user: The recruiter who reported this deserves a clear, non-technical response quickly. Something like: "You were right to report this. This was a phishing attempt. You did not click the link, so your credentials are safe. We have blocked the sender and removed the email from affected inboxes. Thank you for reporting it." Prompt, clear communication with reporters reinforces the behaviour you want to see. The Anti-Phishing Working Group (APWG) publishes guidance on building a reporting culture that treats users as your first sensor layer.

Enrich intelligence: Submit the IOCs (defanged) to your threat-intel platform, tag them with the campaign context, and note any infrastructure overlaps with previously known phishing kits.

Step 5: Writing the Ticket

A phishing ticket exists for two audiences: the person who will review your work in the next 15 minutes, and the analyst who may need to correlate this campaign six months from now. Both audiences need the same things: a clear verdict up front, the full evidence trail, every IOC documented and defanged, the remediation steps taken, and any open actions outstanding.

A minimal but complete ticket structure looks like this:

TICKET: PHI-2026-0114
Status: Resolved
Severity: High
Analyst: L. Reyes
Reported by: Finance recruiter (ticket ref: SR-4421)
 
VERDICT
Malicious — confirmed credential-harvesting phish targeting direct deposit info.
 
EVIDENCE SUMMARY
- SPF: FAIL  |  DKIM: FAIL  |  DMARC: FAIL (policy=REJECT)
- Sending IP: 198.51.100.47 (resolves to mail-send[.]phish-infra[.]net, not a GCI asset)
- Reply-To mismatch: fastmail-svc[.]xyz (registered 2026-05-27, 14 days old at time of receipt)
- Payload URL: hxxps://direct-deposit-update[.]globalcorpinc-hr[.]workers[.]dev/portal?token=eyJ0...
- Attachment: Direct_Deposit_Update_Form.docm
  SHA-256: 3b4a2f1e8d7c9b0a... (VirusTotal: 31/72 detections — Trojan.Downloader family)
- SIEM sweep: 14 additional recipients in last 48h; 0 additional reporters; 0 clicked links confirmed
 
REMEDIATION TAKEN
1. Purged message from all 15 affected inboxes via Defender for Office 365 (09:54 UTC)
2. Blocked sending IP and phish domain at email gateway (10:02 UTC)
3. Blocked workers.dev subdomain at web proxy (10:07 UTC)
4. Notified all 15 recipients via IT Security advisory email (10:15 UTC)
5. IOCs submitted to threat-intel platform (tags: phishing, BEC-adjacent, direct-deposit-fraud)
 
OPEN ACTIONS
- Notify payroll team to monitor for fraudulent direct-deposit change requests (assigned: HR Security Liaison)
- Submit campaign data to APWG (assigned: analyst)

Notice the verdict comes first. A reviewer scanning twenty tickets during an incident should not have to read to the bottom to find out whether this was a real attack or a false alarm. The MITRE ATT&CK mapping for this scenario is T1566.001 (Phishing: Spearphishing Attachment) and T1598.003 (Phishing for Information: Spearphishing via Email), which you would include in the ticket for MITRE breadth tracking.

Where New Analysts Slow Down

The step that separates a confident verdict from a guess is header reading, and it is the step most people rush. The authentication results and the Received chain answer the impersonation question before you have even looked at the body, yet the instinct under queue pressure is to skim them. Slowing down for those thirty seconds, every time, is the single habit that most improves phishing verdicts. The user who reported this one hovered before clicking; the next user may not, and the analyst working that ticket at 09:17 may be you in your third week.

SOCSimulator's training operations include full phishing investigation scenarios where you handle user-reported emails, parse real-looking headers, defang and triage URLs, and write investigation tickets — all in a consequence-free environment that mirrors exactly what this walkthrough covers.

To sharpen the pattern recognition that drives a fast verdict, work through 15 phishing email examples analyzed like a SOC analyst would: the recurring header tells and lure structures become obvious once you have seen enough of them side by side. For broader context on the day-to-day, What Does a SOC Analyst Do? maps the full role, How to Become a SOC Analyst covers the certification and skill path, and SOC Analyst Interview Questions includes the header-analysis and phishing-triage scenarios that appear in Tier 1 interviews regularly.

Phishing investigation is one of the highest-frequency skills in Tier 1. It rewards analysts who slow down in the first thirty seconds, read the header before the body, and document their reasoning clearly enough that anyone on the team can pick up the ticket and continue. That discipline is learnable — it only requires practice on the right kind of scenarios.

The MITRE ATT&CK mapping for a full phishing chain covers T1566 (Phishing) at the top level, with T1566.001 (Spearphishing Attachment) and T1566.002 (Spearphishing Link) as the two most common sub-techniques. Including these in your ticket connects the investigation to your organization's MITRE coverage tracking.

Copy-Paste Ticket Template

VERDICT: [Phishing / Spear-phishing / Legitimate / Uncertain]
 
EVIDENCE:
  - Header: [From/Reply-To mismatch, SPF/DKIM/DMARC status]
  - URL: [landing page, redirect chain]
  - Attachment: [hash, file type, behavior]
 
IOCs:
  - Sender domain:
  - URLs:
  - File hashes:
 
ACTIONS:
  - User notified: [Y/N]
  - Email quarantined: [Y/N]
  - Domain blocked: [Y/N]
  - Ticket escalated: [Y/N, tier]