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. Both findings describe the same pre-attack step, acquiring infrastructure, and it is the part of the sequence none of your logs witnessed: the host was rented and the name registered days before this message existed. Treat the answer as a scoping tool rather than a verdict. A creation date inside the last month makes the domain worth sweeping across your whole DNS estate and not just this mailbox, because operators rarely stand up one name at a time.

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.

That token also changes what your tooling can tell you. Kits routinely answer a request that arrives without the victim's parameter with a decoy page, a redirect to the real brand site, or a plain 404, so a clean reputation verdict on a trimmed link proves very little. It is worth naming what this half of the mail is doing, too: the link solicits credentials rather than delivering code, which ATT&CK files under phishing for information in Reconnaissance, well ahead of anything an endpoint tool would ever see.

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.

Both come back clean when the link really is a vendor's own domain, which is the mechanic behind device code phishing. A reputation verdict answers "is this host known bad," never "should this user be authenticating here right now."

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.

The field names below (src_ip, reply_to, url, subject, recipient) are placeholders, because each gateway's sourcetype names them differently; map them to yours before you run it. The values are live strings, not defanged ones. globalcorpinc-hr[.]workers[.]dev in a search matches nothing, so re-fang in the search bar and keep the brackets in the ticket.

index=email_gateway earliest=-48h
  (src_ip="198.51.100.47"
   OR reply_to="reply-here@fastmail-svc.xyz"
   OR url="*globalcorpinc-hr.workers.dev*"
   OR subject="ACTION REQUIRED: Update Your Direct Deposit Information")
| stats count values(subject) AS subjects values(src_ip) AS src_ips by recipient
| 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.

Finding Every Recipient Across the Tenant

The Splunk search assumes your gateway logs reach a SIEM. In a Microsoft 365 tenant with Defender for Office 365, advanced hunting answers who received it and who clicked in a single query. EmailEvents has one row per recipient per message, EmailUrlInfo has the URLs pulled from each message, and UrlClickEvents has the Safe Links click records. All three carry NetworkMessageId.

// Defender XDR advanced hunting: every copy of the lure, where it sits now, who clicked
let lookback = 7d;
let phishIp = "198.51.100.47";
let phishHost = "direct-deposit-update.globalcorpinc-hr.workers.dev";
let byUrl = EmailUrlInfo
    | where Timestamp > ago(lookback)
    | where UrlDomain =~ phishHost
    | distinct NetworkMessageId;
let clicks = UrlClickEvents
    | where Timestamp > ago(lookback)
    | where Url contains phishHost
    | summarize FirstClick = min(Timestamp),
                ClickActions = make_set(ActionType),
                ClickedThrough = max(toint(IsClickedThrough))
        by NetworkMessageId, Recipient = tolower(AccountUpn);
EmailEvents
| where Timestamp > ago(lookback)
| where SenderIPv4 == phishIp or NetworkMessageId in (byUrl)
| extend Recipient = tolower(RecipientEmailAddress)
| join kind=leftouter clicks on NetworkMessageId, Recipient
| project Timestamp, RecipientEmailAddress, SenderFromAddress, Subject,
          DeliveryAction, LatestDeliveryLocation, FirstClick, ClickActions, ClickedThrough
| sort by FirstClick desc

Matching on the URL host as well as the sending IP catches copies that went out through a second relay, and campaigns rotate relays. LatestDeliveryLocation shows where each copy sits now, so running the same query after the purge proves that no row still reads Inbox/Folder. Anyone with a FirstClick value sorts to the top and goes to the next section.

The indicators have to be live strings inside the query. A defanged workers[.]dev matches nothing, so re-fang in the query editor and nowhere else. UrlClickEvents also has blind spots: it only records clicks that passed through Safe Links, and the join uses the account's UPN. A click on a forwarded copy from a personal phone never appears, and a user whose UPN differs from their mail address will not join, so search your proxy and DNS logs for the host as well.

Without advanced hunting, Threat Explorer and message trace in the Exchange admin center produce the same recipient list; Microsoft's phishing incident response playbook walks through both, plus a Purview content search. In Google Workspace, Email Log Search in the Admin console filters by sender, recipient, subject, or sending IP. For messages older than 30 days it requires the recipient address and message ID, so sweep early.

Did Anyone Click?

The answer decides how big this ticket gets. Take it from the click columns above, from the reporter, and from the proxy logs, then follow the branch that matches.

Nobody clicked. Purge, block, notify, close. A Safe Links block with IsClickedThrough at 0 means the user never reached the page. Note the name anyway, because the next lure lands in the same inbox.

Someone clicked through to the credential page. Treat the password as stolen, and do not treat a successful MFA prompt as proof it wasn't used. Adversary-in-the-middle kits proxy the real sign-in page and take the session cookie after MFA completes. In the AiTM campaign Microsoft documented in 2022, the attacker started the follow-on payment fraud as little as five minutes after stealing the cookie, and later created an inbox rule to hide the fraud target's replies. Starting at FirstClick, check that account for:

• Successful sign-ins from an IP, ASN, or country the user has never signed in from, including ones that satisfied MFA.
• New inbox rules and mailbox forwarding, especially rules that move or delete mail or forward it outside the organization. The playbook above has the Exchange Online PowerShell for both.
• MFA methods added or changed after the click.
• Consent granted to an app the user doesn't recognize.

If any of these turns something up, reset the password and revoke the refresh tokens with Revoke-MgUserSignInSession. Revocation does not cut off an access token that was already issued: Entra ID access tokens last one hour by default, so a hijacked session can keep reading mail until it expires.

Someone opened the attachment. This one moves to the endpoint. Pull the device timeline in your EDR and look for child processes under WINWORD.EXE in the minutes after the open. A macro document that launched PowerShell or a script host has left phishing triage behind.

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.

That last item is staging a capability in ATT&CK terms: the kit was uploaded and answering requests before the mail was ever sent, which is why the only trace of it you will ever hold is your own proxy log from the moment somebody reached it. It also decides the shape of the block. Blocking the full path leaves the kit live for the next lure on the same host, so the proxy rule wants the subdomain, and the hunt for other recipients wants the host, not the full URL.

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, Email Log Search only finds the copies. Removing them from users' mailboxes is done in the security investigation tool, which works from Gmail log data and is not included in every edition (check the editions listed on that page). 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.

Close or Escalate to Incident Response

Close the ticket at Tier 1 when every one of these holds: the re-run query shows no copy left in an inbox; nobody reached the page, or the clicker's sign-ins, mailbox rules, MFA methods, and app consents came back clean from the click onward; the sending IP, the host, and the attachment hash are blocked; every recipient has been told.

Escalate to incident response if any one of these is true:

• A sign-in from attacker infrastructure succeeded after the click.
• A new inbox rule, forwarding address, MFA method, or app consent appeared on a recipient's account.
• The attachment executed and spawned a process.
• The person who clicked holds an admin role or approves payments. In this scenario, a direct deposit change request for any recipient escalates on its own, whatever the sign-in logs say.
• The campaign reached more mailboxes than you can check inside your SLA.

Hand over the query output as it stands. The IR lead needs the NetworkMessageId values and click timestamps to pull the messages and build the timeline without repeating your scoping.

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, and 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]