Incident Response Playbook: Suspicious Email Analysis

Note

Executive Summary: Phishing and malicious email delivery remain the primary initial access vectors for most cyberattacks. This playbook provides a structured, step-by-step methodology for safely dissecting suspicious .eml or .msg files. The objective is to determine the true origin of the message, validate its cryptographic authenticity, extract actionable Indicators of Compromise (IOCs), and pivot to enterprise-wide threat hunting.

1. Operational Security (OPSEC) and Preparation

The golden rule of email analysis is Zero Trust. The analyst must never assume the safety of the sample or double-click the file within a standard operating environment.

1. Isolation: Conduct all analyses within a secure, isolated environment. Utilize a dedicated forensic Virtual Machine (VM) configured in “Host-Only” network mode to prevent accidental payload detonation or call-home beacons (e.g., tracking pixels).
2. Safe Tooling: Never open the sample using a mail client (like Outlook or Thunderbird) as they may automatically render malicious HTML or execute embedded scripts. Use raw text editors (Notepad++, VS Code) or command-line utilities (cat, less) to inspect the raw MIME structure.

2. Header Analysis: The Interrogation Room

Email headers are the definitive source of truth for tracing a message’s origin. They document the exact path the email took across the internet. Headers must be read from bottom to top.

A. Tracing the Origin (Received: headers)

Locate the series of Received: headers. The first Received: header (the one closest to the bottom of the header block) typically reveals the original Source IP address of the sender.

• Action: Query this IP against Threat Intelligence feeds (AbuseIPDB, Talos Intelligence, VirusTotal) to assess its reputation, ASN, and geographic location.

B. Cryptographic Authentication (SPF, DKIM, DMARC)

Locate the Authentication-Results header. This contains the verdict from the first trusted receiving server (e.g., Microsoft 365 or Google Workspace).

SPF (Sender Policy Framework)

Verifies if the sending IP is authorized by the domain owner. A spf=fail or softfail indicates an unauthorized sender. Note: SPF checks the Return-Path domain, not the visible From: address.

DKIM (DomainKeys Identified Mail)

Ensures message integrity. A dkim=fail means the cryptographic signature is invalid, suggesting the email was altered in transit or the signing key is forged.

DMARC (Domain-based Message Authentication)

Binds SPF and DKIM to the visible From: address. A dmarc=fail is the strongest technical indicator of a domain spoofing attempt. Look for the policy applied (e.g., p=quarantine or p=reject).

C. Detecting Spoofing Mechanics

Adversaries often manipulate display addresses to deceive the recipient. Compare the following fields:

• From: The address displayed to the end-user.
• Return-Path: The envelope sender (MAIL FROM), used for bounce messages and SPF checks.
• Reply-To: The address where the victim’s reply will actually be sent.
• Verdict: If the From: is ceo@yourcompany.com, but the Return-Path is attacker@russian-domain.ru and the Reply-To is a free webmail address, it is a confirmed spoofing campaign.

3. Body and Payload Triage

Analyzing the Body (The Trap)

• Semantic Analysis: Look for social engineering hallmarks: a false sense of urgency, unusual financial requests, or atypical grammar.
• URL Extraction: Do not click links. Extract the URLs safely using a text editor. Compare the display text (e.g., https://secure-bank.com) with the actual href destination (http://evil-phishing-domain.com).
• Safe Evaluation: Submit extracted URLs to sandboxing services like urlscan.io or VirusTotal to safely render the destination page and analyze its DOM without risking exposure.

Analyzing Attachments (The Weapon)

• Safe Extraction: Use specialized Python scripts or forensic tools (like emlAnalyzer) to extract the attachment without executing it.
• Static Triage: Calculate the SHA256 hash of the attachment and query it on VirusTotal. If the file is unknown, it must be forwarded to a secure sandbox for deeper malware analysis (PE header inspection, strings extraction).

4. Threat Hunting and Eradication

Once the analysis concludes, the extracted IOCs must be weaponized to sweep the enterprise environment and eradicate the threat.

KQL (Defender for Office 365)

hunt_malicious_email.kql

// Hunt for all emails received from the malicious sender IP or containing the bad URL
EmailEvents
| where SenderIPv4 == "198.51.100.42" or SenderMailFromAddress == "attacker@evil.com"
| join kind=inner EmailUrlInfo on NetworkMessageId
| where Url contains "evil-phishing-domain.com"
| project Timestamp, Subject, SenderFromAddress, RecipientEmailAddress, DeliveryAction

Splunk (Mail Gateway Logs)

hunt_mail_gateway.spl

# Search email gateway logs for the malicious sender or specific attachment hash
index=email sourcetype=cisco:esa OR sourcetype=proofpoint
(src_ip="198.51.100.42" OR sender="*@evil.com" OR file_hash="e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855")
| table _time, recipient, sender, subject, action, file_name

If the hunting queries reveal that a user successfully clicked the link or downloaded the attachment, immediately transition to theEDR Alert Triage Playbook to contain the compromised endpoint.

---

References & Further Reading

• SANS Institute: Analyzing Malicious Emails
• Related Playbook: Threat Hunting for Persistence
• Related Playbook: EDR Alert Triage Methodology