6.2 Email Header Forensics, Link Triage, and Malicious Attachment Analysis

Email Header Forensics, Link Triage, and Malicious Attachment Analysis

When a suspicious email penetrates perimeter defenses, incident handlers must execute forensic triage across three core components: RFC 5322 header metadata, embedded hyperlinks, and attached file payloads. Methodical analysis allows defenders to reconstruct the message's genuine origin, isolate intermediate hops, assess domain reputation, and safely de-obfuscate embedded routines without live execution.

RFC 5322 and RFC 5321 Message Architecture

Every email message consists of two distinct layers governed by internet standards:

• RFC 5321 (The SMTP Envelope): Handled directly by Mail Transfer Agents (MTAs). Specifies MAIL FROM (bounce address for non-delivery receipts) and RCPT TO (recipient). The envelope is discarded or encapsulated upon final delivery and is invisible in email client viewports.
• RFC 5322 (Message Headers and Body): Displayed by the Mail User Agent (MUA, e.g., Outlook). Includes visible From:, To:, Subject:, Date:, and Reply-To: fields, followed by the body.

Because SMTP lacks synchronization between envelope and header layers, attackers decouple them—specifying a benign external domain in the envelope to satisfy transport rules while forging an internal executive domain in the visible From: header.

Email Header Forensics: The Chronological Inspection Methodology

Email headers can document a routing trail, but only headers added by trusted infrastructure are reliable. Start from the receiver-controlled top of the chain, identify the organization's border hop, and trace toward the earliest trusted entry rather than blindly trusting the bottom line.

The Bottom-to-Top Rule

Each intermediate MTA that processes an email prepends a new Received: header to the very top of the existing header block. Consequently:

• The Lowest Received: Header: Purports to represent the earliest submission, but it can be attacker-supplied and must not be trusted until anchored to a header added by known infrastructure.
• The Topmost Received: Header: Represents the final internal mail server depositing the message into the recipient's mailbox.

Anatomy of a Received: Header

A standardized Received: header contains critical forensic artifacts:

Received: from mail.attacker-relay.com (198.51.100.25)
    by seg.victimcorp.com (203.0.113.10) with ESMTP id m12345
    for [target@victimcorp.com]; Thu, 03 Oct 2026 14:22:10 -0400

• from: Declares the hostname and connecting IP address of the sending host as recorded by the receiving server.
• by: Identifies the receiving mail server that accepted the connection.
• with: The mail transmission protocol used (e.g., ESMTP or ESMTPS with TLS ciphers).
• for: The designated recipient address.
• timestamp: The date and time recorded by the receiving server's clock.

Detecting Forged Headers and Spoofing

Because senders control their outbound mail servers, adversaries can inject fabricated Received: headers below their genuine entry point to simulate routing through legitimate infrastructure. However, adversaries cannot forge the first Received: header generated by the victim's border gateway (e.g., an edge Secure Email Gateway), which records the external SMTP peer it observed during the TCP connection. That peer may itself be a relay, VPN exit, bot, or compromised server.

Critical Forensic Header Fields

• Return-Path: Populated by the destination MTA from the SMTP envelope MAIL FROM. Indicates where delivery bounce notices are routed.
• Reply-To: Instructs the recipient's MUA where to send responses. If an email displays From: ceo@victimcorp.com but specifies Reply-To: attacker@external.com, replies bypass corporate mail systems and route directly to the adversary.
• Message-ID: A globally unique string assigned by the originating MTA. Inconsistent domains, irregular syntax, or timestamps that conflict with Received headers reveal automated phishing toolkits.
• Authentication-Results: Injected by the receiving gateway, summarizing technical verification verdicts for SPF, DKIM, and DMARC (e.g., spf=pass, dkim=pass, dmarc=pass).
• X-Originating-IP / X-Sender-IP: Non-standard extension headers added by certain webmail providers or MTAs reflecting the client's public IP address behind a webmail interface.

Suspicious Link Triage and URL Analysis

Phishing messages frequently contain embedded hyperlinks leading to credential harvesting portals or exploit payloads. Incident handlers must triage links safely:

• Defanging URLs: Responders neutralize hyperlinks in tickets and reports to prevent accidental browsing (e.g., converting http://malicious-login.com/auth into hxxp[://]malicious-login[.]com/auth).
• Analyzing Redirection Chains: Attackers cloak destinations using HTTP redirects (301 Moved Permanently, 302 Found), open redirects, or URL shorteners. Handlers trace hops using command-line tools without executing JavaScript:

  curl -s -IL --max-redirs 5 -A "Mozilla/5.0" "hxxp://short[.]link/xyz"
  

• Reputation and Sandboxing: Submitting URLs to platforms (VirusTotal, urlscan.io) exposes DOM structure, network calls, screenshots, and SSL certificates.
• Passive DNS (pDNS): Evaluating domain age and resolution changes via pDNS uncovers newly registered domains (NRDs) and fast-flux infrastructure.

Malicious Attachment Triage and Static Analysis

When an email delivers an attachment, responders conduct static analysis in an isolated sandbox environment:

• Cryptographic Hashing: Calculating SHA-256 hashes of attachments enables rapid correlation across threat intelligence platforms.
• Macro Extraction with oledump.py: Microsoft Office Compound File Binary Format (OLE) files contain structured streams. Using Didier Stevens' oledump.py, analysts scan for macros:
  • Running python oledump.py maldoc.doc lists streams.
  • A lowercase 'm' indicates macro metadata; an uppercase 'M' denotes an active Visual Basic for Applications (VBA) code stream.
  • Analysts dump specific streams for de-obfuscation: python oledump.py -s 7 -v maldoc.doc.
• Automated De-Obfuscation with olevba: Part of oletools, olevba parses OLE and OpenXML documents, extracting auto-exec triggers (AutoOpen, Document_Open) and suspicious APIs (Shell, WScript.Shell, PowerShell).
• PDF Forensics: Analyzing PDF objects using pdfid and pdf-parser to detect /JavaScript, /Launch, and /EmbeddedFiles.

Email Server Log Investigation

Correlating header artifacts against server telemetry confirms delivery scope and lateral impact:

• Microsoft 365 Message Trace: Enables administrators to search email logs across Exchange Online for the preceding 90 days. Querying by Message-ID, sender address, or subject line identifies every internal recipient who received a phishing blast.
• Exchange Message Tracking Logs: On-premises Exchange servers record message flow across transport services (Get-MessageTrackingLog -MessageId "[id]"), revealing delivery events (RECEIVE, TRANSFER, DELIVER, FAIL).
• Secure Email Gateway (SEG) Logs: Appliance logs (Cisco Secure Email, Proofpoint, Mimecast) provide deep packet inspection details, spam scoring algorithms, sandbox detonation verdicts, and connection-level IP forensics.