Phishing remains the single most common entry point for breaches, and the reason is simple: it targets people, not patches. A well-crafted phishing email can slip past spam filters, mimic a brand you trust, and pressure you into clicking before you think. The good news is that almost every phishing email leaves fingerprints, and once you know where to look, those fingerprints become obvious.
This guide walks through real-world phishing email examples, the technical indicators that give them away, and the exact steps to analyse and report a suspicious message. We will look at email headers, authentication records, malicious attachments, and credential-harvesting links, using professional-grade tooling that analysts rely on every day. If you want to turn this knowledge into hands-on skill, the foundational material in the Introduction to Ethical Hacking course at Redfox Cybersecurity Academy is a strong place to start.
Phishing is no longer riddled with broken English and obvious typos. Modern campaigns use AI-generated copy, pixel-perfect brand templates, and legitimate cloud infrastructure to host their payloads. Attackers increasingly abuse trusted services like SharePoint, Google Docs, and Dropbox so the malicious link points to a domain your filters already allow.
The main categories you will encounter:
Mass phishing casts a wide net with generic lures such as "Your account has been suspended." Spear phishing targets a specific person with personalised detail. Whaling goes after executives and finance staff. Business email compromise (BEC) impersonates a colleague or supplier to redirect payments, often with no malicious link at all, just a convincing request.
Recognising the category helps you predict the goal: credential theft, malware delivery, or fraudulent wire transfer.
Here is a typical credential-harvesting email, reproduced as raw text so you can study the structure:
From: "Microsoft 365 Security" <security@m365-account-verify.com>
To: jane.doe@company.com
Subject: [Action Required] Unusual sign-in activity detected
Reply-To: no-reply@m365-account-verify.com
Content-Type: text/html
We detected an unusual sign-in to your account from
Lagos, Nigeria. If this was not you, your account will be
locked within 24 hours.
Verify your identity now:
https://login.microsoftonline.com.account-verify[.]com/auth?id=8842
[cta]
Three red flags stand out immediately. The sender domain m365-account-verify.com has nothing to do with Microsoft. The urgency and the 24-hour deadline are classic pressure tactics. Most importantly, the link looks legitimate at a glance but the real registered domain is account-verify.com, with login.microsoftonline.com used only as a subdomain prefix to fool you.
You can decode the true destination of any URL from the command line. Use curl to follow redirects without rendering the page:
curl -sIL "https://login.microsoftonline.com.account-verify.com/auth?id=8842" \
-A "Mozilla/5.0" | grep -iE "HTTP/|location:"
[cta]
This prints the HTTP status and every Location redirect header, revealing where the link finally lands. Phishing kits frequently chain three or four redirects through link shorteners and compromised sites before reaching the fake login page.
To inspect the page safely without exposing your own IP or credentials, submit it to a URL sandbox through the urlscan.io API:
curl -X POST "https://urlscan.io/api/v1/scan/" \
-H "API-Key: $URLSCAN_API_KEY" \
-H "Content-Type: application/json" \
-d '{"url":"https://login.microsoftonline.com.account-verify.com/auth?id=8842","visibility":"unlisted"}'
[cta]
The response returns a UUID you can poll for a full report: screenshots, DOM content, contacted domains, and any harvested form fields. Learning to read these reports is core to phishing triage, and the analysis workflow is covered in depth in the Web Hacking Basics training at Redfox Cybersecurity Academy.
The body of an email can be faked easily. The headers are far harder to forge cleanly, which is why header analysis is the most reliable technical check you can run.
In most clients you can export the original message. In Outlook, open the message and choose File then Properties to see Internet headers. In Gmail, use the three-dot menu and select "Show original," then download as an .eml file. Once you have the raw message, the Received chain tells the story.
Here is a trimmed header from a spoofed email:
Received: from mail.attacker-vps.xyz (185.234.219.x)
by mx.company.com with ESMTP id abc123
for <jane.doe@company.com>; Tue, 03 Jun 2026 09:12:44 +0000
Received: from [10.0.0.5] (unknown [185.234.219.x])
by mail.attacker-vps.xyz with ESMTPA
Authentication-Results: mx.company.com;
spf=fail (sender IP is 185.234.219.x)
smtp.mailfrom=security@m365-account-verify.com;
dkim=none;
dmarc=fail action=quarantine header.from=microsoft.com
[cta]
Read the Received headers from the bottom up: the lowest one is the origin. Here the message originated from a cheap VPS, not Microsoft infrastructure. The Authentication-Results line is the smoking gun: SPF failed, there is no DKIM signature, and DMARC failed. A legitimate Microsoft email would pass all three.
You can verify a domain's published authentication records yourself with dig:
# Check the SPF record
dig +short TXT microsoft.com | grep -i spf
# Check the DMARC policy
dig +short TXT _dmarc.microsoft.com
# Check a DKIM selector (selector name varies by sender)
dig +short TXT selector1._domainkey.microsoft.com
[cta]
If the sending IP in the headers is not listed in the domain's SPF record, and the DMARC policy is set to p=reject or p=quarantine, a spoofed message should never have reached your inbox in a trusted state. When it does, that mismatch is your evidence. Understanding SPF, DKIM, and DMARC end to end is one of the most practical defensive skills, and it is reinforced throughout the structured path in Redfox Cybersecurity Academy's ethical hacking courses.
The second common pattern delivers malware through an attachment. Invoices, shipping notices, and resumes are the favourite disguises. The dangerous files are rarely plain executables anymore; they are macro-enabled Office documents, OneNote files, ISO images, or HTML smuggling pages.
Suppose you receive Invoice_4471.docm. Never open it. Instead, analyse it in an isolated virtual machine using oletools, the standard suite for Office document forensics. First, get a structural overview:
oleid Invoice_4471.docm
[cta]
oleid flags whether the file contains VBA macros, external relationships, or embedded objects. If macros are present, extract and inspect them with olevba, which also auto-detects suspicious keywords:
olevba --decode --deobf Invoice_4471.docm
[cta]
A malicious macro will often reveal an auto-execution trigger and an obfuscated download routine. The decoded output frequently looks like this:
Sub AutoOpen()
Dim x As String
x = "powershell -nop -w hidden -enc " & _
"JABjAGwAaQBlAG4AdAAgAD0AIABOAGUAdwAtAE8AYgBqAGUAYwB0..."
Shell x, vbHide
End Sub
[cta]
The AutoOpen subroutine runs the moment the document opens, and the -enc flag passes a Base64-encoded PowerShell command designed to stay hidden. You can decode that payload safely to see its intent without executing anything:
echo "JABjAGwAaQBlAG4AdAAgAD0AIABOAGUAdwAtAE8AYgBqAGUAYwB0..." \
| base64 -d | iconv -f UTF-16LE -t UTF-8
[cta]
Decoded, these payloads almost always reveal a New-Object Net.WebClient or Invoke-WebRequest call reaching out to a command-and-control server to pull down the next stage. That outbound URL and IP become indicators of compromise (IOCs) you can block and report.
To confirm a verdict without manual reversing, hash the file and query a threat intelligence service:
sha256sum Invoice_4471.docm
curl -s --request GET \
--url "https://www.virustotal.com/api/v3/files/<SHA256_HASH>" \
--header "x-apikey: $VT_API_KEY" | jq '.data.attributes.last_analysis_stats'
[cta]
The jq filter returns a count of how many engines flagged the file as malicious. If you see detections, you have your answer. This kind of attachment triage maps directly to the malware-analysis foundations taught in the more advanced tracks at Redfox Cybersecurity Academy.
Attackers adapt quickly to defences. Two techniques now dominate because they bypass traditional URL and attachment scanning.
HTML smuggling hides the payload inside a benign-looking HTML attachment. The file contains JavaScript that reconstructs a malicious file in the browser, on the local machine, so nothing malicious crosses the network for a gateway to scan. A simplified smuggling snippet looks like this:
<script>
var data = "TVqQAAMAAAAEAAAA..."; // base64 of an executable
var bytes = atob(data);
var arr = new Uint8Array(bytes.length);
for (var i = 0; i < bytes.length; i++) arr[i] = bytes.charCodeAt(i);
var blob = new Blob([arr], {type: "application/octet-stream"});
var url = URL.createObjectURL(blob);
var a = document.createElement("a");
a.href = url; a.download = "Statement.iso";
a.click();
</script>
[cta]
The atob call decodes an embedded Base64 blob into raw bytes, builds a file in memory, and forces a download. Seeing a large Base64 string passed to atob followed by a Blob and a forced download is a reliable smuggling signature you can grep for across saved attachments.
QR code phishing, sometimes called quishing, embeds the malicious URL inside an image to evade text-based link scanners. If you receive an email pushing you to scan a QR code to "review a document" or "reset MFA," extract and decode the code instead of scanning it with your phone:
# Pull the QR image out of the email, then decode the URL it encodes
zbarimg --quiet --raw qr_attachment.png
[cta]
zbarimg prints the embedded URL as text, which you can then run through the same curl and urlscan checks shown earlier. Never point your personal device at an untrusted QR code, because the goal is to move the attack onto a device with fewer controls.
When a suspicious email arrives, consistency beats guesswork. Build the habit of running the same checks every time. You can even script the first pass against a saved .eml file:
#!/usr/bin/env bash
# quick_triage.sh - first-pass phishing triage
EML="$1"
echo "=== From / Reply-To mismatch ==="
grep -iE "^(from|reply-to):" "$EML"
echo "=== Authentication results ==="
grep -i "Authentication-Results" "$EML"
echo "=== Originating IPs ==="
grep -ioE "\b([0-9]{1,3}\.){3}[0-9]{1,3}\b" "$EML" | sort -u
echo "=== Extracted URLs ==="
grep -ioE "https?://[a-zA-Z0-9./?=_%:-]+" "$EML" | sort -u
[cta]
Run it like bash quick_triage.sh suspicious.eml. In seconds you get the sender mismatch, the authentication verdict, the source IPs, and every URL in the message. From there you escalate to sandboxing and threat-intel lookups only on the items that look suspicious. This systematic approach is exactly how SOC analysts work, and you can build the full skill set through the practical labs at Redfox Cybersecurity Academy.
For organisations that want to measure how staff respond, open-source frameworks like GoPhish let security teams run authorised, ethical phishing-awareness campaigns and track click rates. Used internally and with permission, this turns abstract warnings into measurable behaviour change.
Tools confirm what your instincts should already suspect. Before any command line, train yourself to pause on these signals.
Mismatched or look-alike sender domains, such as paypa1.com or micros0ft-support.net, are a constant tell. Generic greetings like "Dear Customer" from a company that knows your name suggest a mass campaign. Artificial urgency and threats of account closure exist to short-circuit your judgement. Unexpected attachments, especially .docm, .iso, .html, .zip, and .lnk files, deserve suspicion. Requests to change payment details, buy gift cards, or move money "urgently and confidentially" are the hallmark of business email compromise. Finally, hover over every link before clicking and read the real domain from right to left, because the registered domain is always the part immediately before the first single slash.
Do not click links, open attachments, or reply. Replying confirms your address is live and active, which makes you a higher-value target.
Report it using your organisation's process. Most enterprise mail clients have a "Report Phishing" button that sends the message to your security team with full headers intact. If you are an individual, forward the message to the impersonated brand's abuse address and to your national reporting body, such as reportphishing@apwg.org for the Anti-Phishing Working Group.
Preserve the evidence. Export the original .eml or .msg file rather than forwarding a screenshot, because the raw file retains the headers and IOCs that analysts need.
If you already clicked or entered credentials, act fast. Disconnect the device from the network, change the affected password from a different trusted device, revoke active sessions, and enable or reset multi-factor authentication. Tell your security team immediately, because the speed of your response often determines whether an incident stays contained.
Block and hunt. Once you have the malicious domains, IPs, and file hashes, your security team should block them at the firewall and mail gateway, then search logs to confirm no one else interacted with the same campaign. A simple Yara rule built from the IOCs helps catch reuse:
rule Phish_Credential_Harvester_M365 {
meta:
description = "Detects spoofed M365 phishing lure"
author = "SOC Team"
strings:
$domain = "account-verify.com" nocase
$lure = "Unusual sign-in activity detected" nocase
$brand = "Microsoft 365 Security" nocase
condition:
2 of them
}
[cta]
Running this rule across mail stores and quarantine folders surfaces every related message in one pass, turning a single reported email into protection for the whole organisation.
Recognising one phishing email is useful. Understanding the full attack chain, from the lure to the landing page to the payload, is what makes you genuinely hard to fool and valuable to any security team. That depth comes from doing the analysis repeatedly in a safe environment.
The structured courses at Redfox Cybersecurity Academy take you from the fundamentals of how attackers think through hands-on web and application security, with real-world labs rather than theory. If phishing analysis sparked your interest, the natural progression is to learn how the credential-harvesting pages and payloads are actually built and detected, which is precisely what the offensive and defensive tracks cover.
Phishing succeeds by exploiting trust and urgency, not technical weakness, so awareness is your strongest control. Almost every phishing email betrays itself through a mismatched sender domain, a failed SPF, DKIM, or DMARC check, a deceptive link, or an unexpected attachment. Verify before you trust: decode URLs with curl, read headers from the bottom up, check authentication records with dig, and sandbox anything suspicious rather than opening it. If you receive one, do not engage, preserve the original file, report it, and if you clicked, respond immediately by isolating the device and rotating credentials. Turn a single reported email into broad protection by extracting IOCs and writing detection rules.
The difference between a victim and an analyst is not talent, it is method and practice. Build the method here, then sharpen it through the hands-on labs at Redfox Cybersecurity Academy, and the next phishing email that lands in your inbox becomes a puzzle you solve rather than a trap you fall into.
Redfox Cyber Security Inc.
8 The Green, Ste. A, Dover,
Delaware 19901,
United States.
.avif)
