This chapter covers phishing email analysis techniques, a critical skill for the Security Operations domain of the CS0-003 exam. Phishing remains the most common initial attack vector, appearing in approximately 15-20% of exam questions related to threat detection and analysis. You will learn to dissect email headers, analyze URLs and attachments, and interpret authentication results to distinguish legitimate messages from malicious ones. Mastery of these techniques is essential for the CySA+ role, as analysts are often the first line of defense against targeted phishing campaigns.
Jump to a section
Imagine you are a forensic pathologist examining a suspicious death. You don't just look at the body; you dissect every layer. The email header is like the external clothing: it shows where the message came from (sender address), how it was delivered (mail servers), and the route it took. But a clever killer can forge clothes—spoof the sender. So you check the internal organs: the email body and attachments. The body contains the narrative (social engineering), but the real evidence is in the embedded URLs and attachments—like examining stomach contents for poison. You analyze the URL by hovering over it (like checking a pill's label) to see if it matches the displayed text. Attachments are like foreign objects; you detonate them in a sandbox (isolated environment) to see their behavior. Finally, you check for digital fingerprints: SPF, DKIM, and DMARC records—like DNA tests. SPF checks if the sending server is authorized; DKIM verifies the email's signature hasn't been tampered with; DMARC tells the receiving server what to do if checks fail. Each layer reveals a clue, and only by combining them can you confidently declare the email was a phishing attempt, just as a pathologist determines the cause of death.
What is Phishing Email Analysis?
Phishing email analysis is the systematic examination of email messages to determine if they are malicious. It involves inspecting email headers, body content, URLs, and attachments to identify indicators of compromise (IOCs) and tactics, techniques, and procedures (TTPs) used by attackers. For the CS0-003 exam, you must be able to perform static analysis (examining the email without interacting with malicious elements) and dynamic analysis (using sandboxes to observe behavior). The goal is to extract actionable intelligence to block further attacks and inform incident response.
Why Phishing Analysis Matters
Phishing bypasses traditional perimeter defenses by targeting human psychology. According to the Verizon DBIR, phishing is involved in over 80% of data breaches. Analysts must quickly triage reported emails to prevent credential theft, malware installation, or business email compromise (BEC). The CS0-003 exam tests your ability to identify phishing indicators, use analysis tools, and recommend remediation steps.
Email Header Analysis
Every email contains headers that provide metadata about its transmission. To view headers in common clients:
Microsoft Outlook: Open message > File > Properties > Internet headers
Gmail: Open message > Click three dots > Show original
Thunderbird: View > Message Source
Key header fields: - From: Display name and email address (easily spoofed) - Reply-To: Where replies go (often different from From) - Return-Path: Where bounces go (used in SPF checks) - Received: List of mail servers the email traversed, in reverse order (topmost is most recent) - Message-ID: Unique identifier; can be used to correlate with other messages - Authentication-Results: Contains SPF, DKIM, and DMARC verdicts
SPF (Sender Policy Framework)
SPF allows domain owners to specify which IP addresses are authorized to send mail on their behalf. The check works as follows: 1. Receiving mail server extracts the domain from the Return-Path header. 2. It queries the DNS for the domain's SPF record (TXT record starting with "v=spf1"). 3. It compares the sending server's IP against the allowed IPs in the record. 4. Result: pass, fail, softfail, neutral, none, or temperror.
Example SPF record:
v=spf1 ip4:192.0.2.0/24 include:_spf.google.com ~allip4:192.0.2.0/24 allows mail from that subnet.
include:_spf.google.com includes Google's SPF record.
~all means softfail for other IPs (marked as suspicious but not rejected).
-all means hard fail (rejected).
DKIM (DomainKeys Identified Mail)
DKIM uses public-key cryptography to sign emails. The signing server adds a DKIM-Signature header containing a hash of the email body and select headers, encrypted with the domain's private key. The receiving server retrieves the public key from DNS (e.g., default._domainkey.example.com) and verifies the signature. If the body or headers were altered in transit, the verification fails.
Example DKIM-Signature header:
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=selector1; h=from:to:subject:date:message-id; bh=...; b=...v=1: version
a=rsa-sha256: signing algorithm
c=relaxed/relaxed: canonicalization (relaxed allows minor whitespace changes)
d=example.com: signing domain
s=selector1: selector for the public key in DNS
h=...: headers that were signed
bh=...: body hash
b=...: signature
DMARC (Domain-based Message Authentication, Reporting & Conformance)
DMARC builds on SPF and DKIM. The domain owner publishes a policy in DNS that tells receivers what to do if SPF and/or DKIM fail. DMARC also requires alignment: the domain in the From header must match the domain used in SPF (Return-Path) or DKIM (d=).
DMARC record example:
v=DMARC1; p=reject; rua=mailto:dmarc@example.com; pct=100p=reject: policy for failures (none, quarantine, reject)
rua: aggregate reporting address
pct: percentage of messages subject to policy
The receiving server checks: 1. SPF pass and alignment? (domain in From matches Return-Path domain) 2. DKIM pass and alignment? (domain in From matches d= domain) 3. If either passes with alignment, DMARC passes. 4. Otherwise, apply policy (p=).
URL Analysis
Phishing emails contain links to malicious sites. Techniques: - Hovering: Hover over the link to see the actual URL (tooltip). The displayed text may differ (e.g., "https://google.com" links to "http://evil.com"). - Decoding obfuscation: Attackers use URL shorteners (bit.ly, tinyurl), IP addresses, or hex encoding. - WHOIS lookup: Check domain registration date (recent domains are suspicious). - Sandbox browsing: Use a tool like VirusTotal or a custom sandbox to visit the URL safely.
Attachment Analysis
Attachments can contain malware (macros, scripts, executables). Steps:
1. File extension spoofing: Windows hides known extensions; an attacker may name a file "invoice.pdf.exe" but the displayed name is "invoice.pdf".
2. Hash calculation: Compute MD5/SHA-256 and check against threat intelligence (VirusTotal).
3. Static analysis: Examine metadata, strings, and structure without execution (e.g., using file command, strings, pdfid).
4. Dynamic analysis: Execute in a sandbox to observe behavior (network connections, file system changes).
Common Phishing Indicators
Generic greetings ("Dear Customer" instead of name)
Urgent language ("Your account will be closed")
Spelling/grammar errors
Mismatched URLs
Suspicious sender domain (e.g., "rnicrosoft.com" vs "microsoft.com")
Request for credentials or personal info
Unusual attachment types (.docm, .xlsm, .js, .exe)
Analysis Workflow
Triage: Collect the email as an .eml or .msg file. Isolate the system if user clicked.
Header analysis: Extract sender, routing, and authentication results.
URL analysis: Extract all URLs, decode, check reputation.
Attachment analysis: Hash, scan, sandbox.
Correlation: Cross-reference IOCs with threat intelligence.
Reporting: Document findings and recommend blocks (email rules, domain blacklists).
Tools for Phishing Analysis
Built-in: Email client header viewers, curl, nslookup for DNS.
Online: VirusTotal, URLScan.io, MXToolbox, PhishTool.
Offline: Thunderbird with headers, Wireshark for SMTP traffic, Python scripts.
Email Security Controls
Spam filters: Heuristic and signature-based.
Sender authentication: SPF, DKIM, DMARC.
Sandboxing: Detonate attachments in isolated environments.
User training: Simulated phishing campaigns.
Exam Relevance
On the CS0-003, you will be given sample headers or email content and asked to identify phishing indicators, interpret authentication results, or recommend next steps. Know the difference between SPF fail and DKIM fail, and how DMARC policy affects delivery. Be able to spot a spoofed sender by checking Received headers and authentication-results.
Collect and Preserve the Email
Obtain the full email message including headers. In most clients, you can download the .eml file or copy the original source. Preserve integrity: do not click links or open attachments. Hash the file (SHA-256) for later evidence. Document the user's report, including when they received it and any actions they took. This step is critical for chain of custody and for subsequent analysis.
Analyze Email Headers
Extract and examine headers. Look for the Received chain: the first Received entry (top) is the last server; the last Received entry is the originating server. Check the From, Reply-To, and Return-Path for inconsistencies. Examine Authentication-Results for SPF, DKIM, and DMARC verdicts. A 'fail' or 'softfail' indicates potential spoofing. Note the Message-ID and any X-headers added by security gateways.
Extract and Analyze URLs
List all hyperlinks in the email. Hover over each to reveal the actual URL. Look for redirects, URL shorteners, or domains that mimic legitimate ones (homoglyphs). Use a tool like `curl -I` to inspect the redirect chain without visiting the final site. Check the domain age via WHOIS. Submit URLs to VirusTotal or URLScan.io for reputation analysis. Do not click directly; use a sandbox or proxy.
Examine Attachments Safely
Identify attachment types. If the extension is .docm, .xlsm, .pptm, .js, .vbs, .exe, or .scr, treat as high risk. Calculate the file hash and search threat intelligence platforms. Use static analysis tools (e.g., `file`, `pdfid`, `olevba`) to detect macros or embedded objects. If safe, detonate in a sandbox like Cuckoo or Joe Sandbox to observe behavior. Never open on a production system.
Correlate and Report Findings
Combine all IOCs: sender IP, domains, URLs, file hashes, and patterns. Cross-reference with internal threat intelligence or feeds like AlienVault OTX. Determine if the email is part of a broader campaign. Document the analysis in a report: summary, indicators, risk level, and recommended actions (block sender, add email rule, blacklist domain, scan user's system). Escalate to incident response if compromise is suspected.
In a large enterprise, phishing analysis is often performed by a SOC analyst using a ticketing system like ServiceNow integrated with email security gateways. For example, a user reports a suspicious email claiming to be from the CEO requesting an urgent wire transfer. The analyst retrieves the .eml from the gateway's quarantine. Header analysis reveals the Return-Path domain is 'example.com' but the From domain is 'company.com'. SPF fails because the sending IP (203.0.113.5) is not authorized for 'company.com'. DKIM is absent. DMARC policy is 'p=reject', so the email should have been rejected, but the gateway was misconfigured to allow quarantine instead. The analyst notes this misconfiguration and recommends fixing DMARC enforcement.
Another scenario: a healthcare organization receives phishing emails with PDF attachments claiming to be lab results. The analyst extracts the PDF hash (MD5: 5d41402abc4b2a76b9719d911017c592) and checks VirusTotal; it's flagged by 20 engines as containing a macro that downloads malware. The analyst uses a sandbox to observe the macro connecting to a C2 server at 198.51.100.10. The analyst blocks the IP at the firewall and adds a mail rule to delete emails with that attachment hash.
A common misconfiguration: an organization sets SPF to softfail (~all) instead of hardfail (-all). Attackers can still deliver emails that appear suspicious but are not rejected. The analyst must understand that only hardfail triggers DMARC rejection. Performance considerations: header parsing can be automated using scripts (Python, PowerShell) to handle thousands of emails daily. However, sandboxing attachments is resource-intensive; prioritize high-risk attachments (executables, macros) and use static analysis for lower-risk files like PDFs.
The CS0-003 exam (Objective 1.2) tests phishing email analysis with a focus on interpreting headers and authentication results. Common wrong answers include: 1. Choosing 'SPF fail' as definitive proof of phishing – SPF alone is not enough; the domain may have a misconfigured SPF record. The correct answer often requires checking DMARC alignment. 2. Assuming DKIM pass means the email is safe – DKIM only verifies integrity, not the sender's identity. An attacker can use their own domain with valid DKIM. 3. Overlooking the Reply-To header – Many candidates focus only on From. The Reply-To can be different and is a strong indicator of BEC. 4. Misinterpreting Received headers – Candidates may think the last Received is the originating server, but it's actually the first hop. The top Received is the most recent.
Specific values to memorize:
SPF mechanisms: ip4, ip6, include, exists, all (with +, -, ~, ?).
DMARC policies: p=none, p=quarantine, p=reject.
Email file formats: .eml (RFC 822), .msg (Outlook).
Common ports: SMTP (25, 587, 465), IMAP (143, 993), POP3 (110, 995).
Edge cases the exam loves: - Forwarded emails: Headers may show multiple Received chains; the original sender is in the inner headers. - BCC recipients: Not visible in headers; use Message-ID to correlate. - Mail list emails: Headers include List-Unsubscribe, List-ID; may have multiple DKIM signatures.
To eliminate wrong answers, ask: Does the authentication result show alignment? Is the domain in the From header consistent with the SPF/DKIM domain? If not, the email is likely spoofed.
Always check the Reply-To header; it often reveals the true attacker's address in BEC.
SPF fail alone does not confirm phishing; DMARC alignment is required.
DKIM pass only means content integrity; it does not authenticate the sender.
DMARC policy of 'reject' will drop emails that fail SPF or DKIM alignment.
URLs can be obfuscated; always decode and check the actual destination.
Attachment hashes should be checked against VirusTotal or other threat intel.
Received headers show the email path; the topmost entry is the most recent server.
Phishing emails often use urgency and generic greetings to bypass suspicion.
Sandbox analysis is essential for dynamic analysis of attachments and URLs.
User training and simulated phishing reduce the risk of successful attacks.
These come up on the exam all the time. Here's how to tell them apart.
SPF (Sender Policy Framework)
Checks if sending IP is authorized by domain owner
Uses DNS TXT records to list authorized IPs
Fails if email is forwarded (IP changes)
Does not protect email content integrity
Simple to implement but limited to IP verification
DKIM (DomainKeys Identified Mail)
Verifies email content has not been tampered with
Uses public-key cryptography with DNS published keys
Survives forwarding if the signature is preserved
Does not verify sender identity (only integrity)
More complex but provides stronger assurance
Mistake
If SPF passes, the email is legitimate.
Correct
SPF only verifies the sending server's IP is authorized for the Return-Path domain. The From header can still be spoofed. DMARC alignment is required to link the From domain to the authenticated domain.
Mistake
A DKIM signature guarantees the email came from the claimed domain.
Correct
DKIM only ensures the email content was not altered in transit. The domain in the d= tag may be different from the From domain. An attacker can sign with their own domain and set the From to a victim domain.
Mistake
DMARC policy of 'none' means the email is safe.
Correct
p=none means no action is taken on failures; the email is delivered normally. It is used for monitoring only. Attackers can still send spoofed emails that pass SPF/DKIM but fail alignment.
Mistake
A URL that displays a legitimate domain is safe.
Correct
The displayed text can be manipulated using HTML anchor tags. Hovering reveals the actual href, which may point to a malicious site. Always check the underlying link.
Mistake
Email headers are always accurate and cannot be forged.
Correct
Headers like From and Reply-To can be easily spoofed. However, Received headers are added by each mail server and are harder to forge. Authentication results (SPF, DKIM, DMARC) are more reliable but can be misconfigured.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Open the email, click the three dots (More) in the top right, and select 'Show original'. A new tab opens displaying the full headers and body. You can download the .eml file. Look for 'Authentication-Results' to see SPF, DKIM, and DMARC verdicts. Use the 'Received' fields to trace the path.
Softfail (~all) indicates that the sending IP is not authorized but the domain owner requests the receiver to mark the email as suspicious rather than reject it. It is often used for testing. On the exam, softfail is considered a fail for DMARC alignment, but the email may still be delivered.
Quarantine (p=quarantine) instructs the receiving server to place the email in the spam folder. Reject (p=reject) instructs the server to reject the email outright (SMTP 550). The exam may ask which policy provides the strongest protection: reject.
Check the From and Return-Path domains. If they differ, it's suspicious. Look at the first Received header (originating server) and compare its IP with the domain's MX records. Use authentication results: if SPF fails and DKIM fails, and DMARC policy is reject, the email should not have reached the inbox.
Homoglyphs are characters that look similar to legitimate ones, like replacing 'o' with '0' or using Cyrillic 'а' (which looks like Latin 'a'). For example, 'rnicrosoft.com' uses 'rn' instead of 'm'. In URLs, this can trick users into visiting fake sites. Analysts should copy the URL into a text editor to see the actual characters.
Message-ID is a unique identifier for each email. It can be used to correlate related emails (e.g., same campaign) and to track emails across different systems. If you see the same Message-ID in multiple emails, they may be part of a phishing campaign.
Isolate the user's machine from the network immediately (disable switch port or disconnect Wi-Fi). Perform a full antivirus scan. Collect the email and any artifacts. Check for outbound connections to known malicious IPs. Escalate to incident response. Change the user's passwords and enforce MFA.
You've just covered Phishing Email Analysis Techniques — now see how well it sticks with free CS0-003 practice questions. Full explanations included, no account needed.
Done with this chapter?