Embedded Files
Email phishing remains one of the most persistent and effective attack vectors in cybersecurity due to its low cost and high reward. Threat actors can use phishing as part of reconnaissance (identifying which email boxes are active or which email systems have weak email security) to gather sensitive information (such as user credentials), and/or as part of their initial access strategy (deliver malware). Threat actors will use email phishing attacks against a random or broad spectrum array of targets (easiest to detect and mitigate) or target their emails at specific individuals - spear phishing, whaling, or business email compromise (see Phishing Attacks).
Real-World Phishing Attack Case Studies
Google and Facebook Phishing Attack (2013 - 2015) - Threat actors sent fake invoices pretending to be from Quanta (a vendor used by both organizations) for payment, resulting in a financial loss of $100 million ($49.7 million recovered).
Colonial Pipeline Phishing Attack (2021) - threat actors used phishing to gain initial access to compromise networks and billing systems before launching a ransomware attack, resulting in a financial loss of $4.4 million (paid as a ransom).
Ukraine Power Grid Outage (2015) - initial access was attributed to a spear phishing attack that caused power outages affecting 230,000 people.
Email phishing analysis is a subset of the previously covered phishing analysis methodology, specifically focused on analyzing emails to determine if they are malicious and part of an active phishing campaign. With phishing email analysis, cybersecurity analysts can proceed to Phase 2 - Collecting Artifacts, as Phase 1 - Identifying the Delivery Channel is complete.
To perform phishing email analysis, the following steps are recommended:
Do not rely on forwarded emails for review; the original email header will not be available for accurate analysis.
Request that the person forward the suspected email as an ‘.eml’ file; this will preserve all email artifacts, including headers, links, and attachments.
Do not rely entirely on the email header field values during analysis, as many of these can be falsified. Cross-check each field value to identify inconsistencies that may indicate a phishing email.
Email Components
Email Components
From the point an email is sent, it traverses the internet, possibly routed through several servers, before arriving at its destined mail server and mailbox. From the start, several pieces of information are typically attached to the email, including the From and To addresses, IP addresses, etc. If these email artifacts are authentic, they will ‘tell’ a consistent story of the email’s journey and verify its authenticity. If several key artifacts are inconsistent, then it is likely the email is not authentic and is part of a phishing attack.
TIP: Some artifacts (Indicators of Compromise) may not be included in an email due to a lack or misconfiguration of the originating mail server. This alone does not indicate a phishing email. A holistic analysis of all email artifacts is needed to confirm the illegitimacy of an email.
These artifacts are grouped into the following email components, each providing IoCs.
Email analysis (a superset to email header analysis) will collect all these artifacts (Phase 2 - Collect Artifacts) for individual analysis.
Header Analysis
Header Analysis
Phishing email analysis steps start with analyzing the email header fields (Phase 3 - Verify Sender Authenticity).
An email header is a metadata block that accompanies every email message. It contains crucial information about the message’s origin, routing, authentication, and other relevant details.
During email header analysis, keep note of the following key header fields:
From: Claimed sender address
To: Intended recipient
Subject: Message subject
Date: Timestamp when the message was sent
Reply-To: Address to which replies are directed
Return-Path: Address to which bounce messages are sent
Received: Log of the MTA servers that processed the email
Message-ID: Unique identifier for the message
Authentication-Results or Received-SPF: Email authentication (SPF, DKIM, DMARC) results
There are many more header fields, but the above will provide a good indication of email phishing.
During email header analysis, the following are red flags to look out for:
Mismatched From Address. It is easily spoofed or faked; check if the sender's display name matches the email address's name and domain.
Subject. Take note of the subject tone (warning, urgent, financial gain, product offer, etc), unusual capitalization, spelling, and grammar mistakes.
IP Addresses. Can be faked; compare the IP address in the initial Received (and X-Sender-IP, if present) field with the IP address associated with the From email address domain or the IP address from the email authentication results.
Suspicious Reply-To or Return-Path. It is not unusual for the Reply-To and From addresses to be different (e.g., the From address is customercare@apple.com and the Reply-To address is noreply@apple.com). However, if the domains of the From, Reply-To, and Return-Path do not match, then the email is likely a phishing attack.
Email Authentication Results. Review the SPF, DKIM, and DMARC authentication results. Do not rely on the results included within the email header, as these can be falsified. Cross-check the results with other artifacts collected, e.g., the source IP address versus the SPF IP address or the DKIM domain versus the source domain.
Look at the example below (Incident 004 - PHISH004_2025), the following artifacts stand out:
From (Red): The email sender display name ‘Microsoft account team’ does not match the actual email address (no-reply@access-accsecurity.com).
From, Reply-To, and Return-Path (Red): The domains of each email address are different and do not support the narrative that it is a legitimate email from Microsoft.
Subject (yellow): Email claims to be from Microsoft regarding unusual account login activity. The choice of words is intended to cause anxiety in the recipient.
Received (purple): The domain and IP address that sent the email (quihdimdfghdrflmnder.co.uk and 89.144.44.42) are not associated with MIcrosoft.
Authentication-Results and Received-SPF (purple): Based on the sending domain and IP address, the SPF authentication fails. Additionally, the DKIM header field is not present, which also fails.
DMARC validation evaluates the alignment and authentication of SPF and DKIM; if either fails, DMARC fails. In the example below, the dmarc=permerror indicates a permanent error occurred during DMARC evaluation - either the DMARC record for the domain was invalid or misconfigured.
Based on the analysis of email header artifacts (and IOCs), it is highly unlikely that the email originates from Microsoft or contains a legitimate warning about a potential account compromise.
For the complete header analysis, refer to the Email Phishing Attack Incident Analysis Report: Incident 004 - PHISH004_2025.
Email header analysis can be done manually using a simple text editor (as above) or using online tools such as MXToolBox Email Header Analyzer, Google Admin ToolBox Messageheader, or Message Header Analyzer. The latter can be locally hosted on your PC and is advisable to avoid uploading sensitive data to platforms owned by third parties.
When using online tools such as MXToolBox, email authentication will be broken down as follows:
SPF Alignment: Checks if the domain of the Return-Path matches that in the From field, either exactly or via organizational domain (depending on strict vs relaxed alignment).
SPF Authentication: Indicates if the sender's IP address is authorized to send emails on behalf of the domain.
DKIM Alignment: Checks if the domain in the 'd=' tag of the DKIM signature matches the domain in the 'From:' header (either an exact match or an organizational match).
DKIM Authentication: Checks whether the digital signature (b=) and body hash (bh=) match the actual content and the public DKIM key. A failure suggests the message may have been altered in transit or DKIM is misconfigured.
Body Analysis
Body Analysis
Viewing email content can be done manually using a decent text editor or using Firefox Thunderbird (an email client).
However, caution is required, as emails that include images, tracking pixels, styling scripts, email tracking scripts, or links will often connect back to their parent server, possibly providing the threat actor with information such as your public IP address, email client, and other details.
Before message/content analysis can proceed, review the Content-Type and Content-Transfer-Encoding header fields to determine if any encoding has been applied to the email message content (see Content-Encoding section under Phishing Evasion Techniques further down). If the email content does not have any encoding applied or decoding is completed, proceed with message analysis.
Message Analysis
Message Analysis
When analyzing the email body or message, look for the following artifacts:
Formatting and Branding:
Does the email attempt to use branding and formatting similar to those of a legitimate company’s email?
This includes specific fonts, color schemes, images, and logos.
If you are familiar with the brand (or can find sample emails via Google search), does anything about the formatting appear off?
Tone:
Does the choice of words indicate a neutral, urgent, threatening, or friendly tone?
A friendly and urgent tone may take the approach of congratulating the recipient or requesting that they complete a survey within a specific time frame to win a prize or receive compensation.
Urgent and threatening tones may indicate that a recipient may have been caught speeding and needs to pay a fine urgently to avoid further prosecution, their account is compromised, or that their antivirus subscription is about to expire.
Specificity:
Does the email use generic salutations - ‘Dear Valued Customer’, ‘Dear Sir’, and ‘Greetings’? Does it not include any salutation? Either can indicate that the email is not meant for a specific recipient.
Does it include the recipient’s correct name, physical address, phone, or email address anywhere in the email?
A lack of specific details may indicate that the email is part of a mass phishing attack campaign.
This particular red flag, however, does not apply to spear phishing, whaling, or business email compromise attacks. These are often crafted and targeted at specific persons and will include their respective details.
Spelling and Grammar:
While perfect spelling and grammar are rare, obvious spelling and grammatical mistakes are common in phishing emails, although they are becoming less common with the advent of Generative AI.
URLs (Hyperlinks):
URL analysis must be conducted carefully to prevent clicking on and accessing the threat actor's web link or page.
URL links are usually easily identifiable by different-colored text within the message text, placed within buttons or images, or displayed for users to see and act on.
Once identified, note them down and follow the techniques outlined in the URL analysis section to find any hidden URLs.
Tracking Pixels and Scripts:
These artifacts are not easily visible when reviewing an email using an email client, but they should stand out when manually reviewing it using a text editor or an email IOC extractor script.
The URLs associated with these artifacts are the moment important element and should be noted down for URL analysis.
In the example ‘Proton’ phishing email, the following can be gleaned from a quick review for the email body content:
Branding & Formatting - The colors and branding do not match Proton’s, and the hyperlink formatting of the button is incorrect.
Tone - The tone, for the most part, is neutral but takes on a threatening (warning) tone when the actor includes the two sentences “Re-Login your account now to avoid closed” and “Login your account to avoid shutdown”.
Spelling and Grammar - Several grammatical mistakes are present, as noted in the tone analysis.
For the complete body analysis, refer to the Email Phishing Attack Incident Analysis Report: Incident 005 - PHISH005_2025.
Google Sites
Report abuse