Tracing Phishing Origins: Raw Email Header Analysis and Indicator Extraction

Most SOC tier-1 playbooks treat email header analysis as a checkbox exercise—verify SPF/DKIM, check the sender domain, move on. That is a mistake. Security Email Gateways (SEGs) drop the ball on spoofed infrastructure constantly because threat actors know how to pass SPF and DKIM on domains they own while displaying high-trust brands in the visible From field.

If you rely strictly on automated gateway verdicts, you miss the actual attack infrastructure. Analyzing raw headers allows you to bypass user-interface abstraction, pinpoint the originating IP, determine whether a relay was abused or compromised, and extract actionable Indicators of Compromise (IOCs) before a campaign lands across your entire enterprise.

The Realistic Raw Header Sample

Here is a raw email header from an inbound phishing campaign designed to bypass basic gateway filters by abusing an open SMTP relay on a compromised web server:

From: "DocuSign Signature Service" <[email protected]>
Reply-To: [email protected]
Message-ID: <[email protected]>
Subject: Action Required: Document Requires Your Immediate Signature

Tracing the Received Chain Bottom-Up

Received: headers are appended sequentially by every Mail Transfer Agent (MTA) that processes the message. Because each hop adds its entry to the top of the stack, you must read Received: headers from bottom to top to trace the chronological path of the email.

The Origin (Bottom-most Hop):
```
Received: from web-php-01.vps-hosting-provider.net (unknown [192.0.2.105])
    by outbound.shared-relay.net (Postfix) with ESMTPSA id 3F91A801
```
The message originated at IP 192.0.2.105 (web-php-01.vps-hosting-provider.net). Notice the protocol ESMTPSA—the A indicates authenticated SMTP. A compromise occurred on this host or using its valid credentials on outbound.shared-relay.net.

The Intermediate Relay (Middle Hop):

Received: from outbound.shared-relay.net (outbound.shared-relay.net [198.51.100.42])
    by mx01.enterprise.local (mta-gateway) with ESMTP id 8A12F98C

The relay 198.51.100.42 handed the email off to our perimeter gateway (mx01.enterprise.local).

Internal Delivery (Top Hop): The internal gateway handed it off to the local store (10.0.1.50).

The true external entry point into your network is 198.51.100.42, but the actual threat actor script ran on 192.0.2.105.

Dissecting Authentication Alignment Failures

Novice analysts often see spf=pass and dkim=pass in the header and assume the email passed checks. Look closely at domain alignment:

Header From: [email protected]
Return-Path (Envelope From): [email protected]
DKIM Signature Domain (header.i): @shared-relay.net

SPF validates the IP sending the message against the domain in the Return-Path (shared-relay.net). Since 198.51.100.42 is an authorized sender for shared-relay.net, SPF passes.

DKIM validates the cryptographic signature against @shared-relay.net. Since shared-relay.net signed the message, DKIM passes.

However, DMARC requires alignment: the domain in the visible From header (docusign.com) must match the domain evaluated by SPF or DKIM (shared-relay.net). Because neither matches docusign.com, DMARC fails:

dmarc=fail (p=REJECT, dis=NONE) header.from=docusign.com;

The attacker used a legit or secondary domain (shared-relay.net) to pass technical checks, relying on legacy email clients or weak gateway settings that render the spoofed From display name without verifying DMARC enforcement.

Profiling Attacker Infrastructure

With the raw IPs and domains isolated from the headers, profile the sending infrastructure using command-line utilities.

Run reverse DNS lookups and ASN queries against both the relay and the originating IP:

# Query PTR record for the originating IP
dig -x 192.0.2.105 +short

# Retrieve WHOIS data for AS owner details
whois -h whois.radb.net 192.0.2.105 | grep -iE "netname|origin|descr"

# Fetch infrastructure metadata via API
curl -s https://ipinfo.io/192.0.2.105/json

From this context, gather two critical points:

Tooling Artifacts: The presence of X-Mailer: PHPMailer 6.8.0 combined with Message-ID formatting ([email protected]) confirms an automated script was used rather than a user client like Outlook or Thunderbird.
Reply-To Decoy: The Reply-To header points to [email protected]. This domain is distinct from the sending infrastructure and serves as the credential harvester target or secondary interaction vector.

Turning Header Artifacts into Block Rules

An investigation without enforcement is useless. Convert the extracted header artifacts into technical controls across your stack.

1. Perimeter IP and Network Blocking

Block the originating IP (192.0.2.105) and the untrusted reply-to domain host at your firewall and secure web gateway level. If the relay IP (198.51.100.42) is a dedicated server (not a massive shared service like Microsoft 365 or SendGrid), block it directly.

2. Transport Rule (Microsoft Exchange / Exchange Online)

To catch variants using the same PHPMailer footprint and spoofing high-value brands:

New-TransportRule -Name "Block PHPMailer DMARC Alignment Bypasses" `
    -HeaderMatchesMessageHeader "X-Mailer" `
    -Patterns "PHPMailer" `
    -HeaderMatchesMessageHeader "Reply-To" `
    -Patterns "\.top$" `
    -SenderDomainIs "docusign.com" `
    -ExceptIfSenderDomainIs "docusign.com" ` # Catches display/header alignment mismatch
    -SetRuleConfidence 6 `
    -WithImportance High `
    -ApplyHtmlDisclaimerLocation "BeforeBody" `
    -Action RejectMessageReasonText "Message rejected due to header anomaly."

3. YARA Rule for Mail Gateway Content Scanning

If your SEG or mail processing pipeline supports YARA scanning on raw email MIME streams, deploy a rule targeting this specific header structure:

rule Phish_PHPMailer_DocuSign_Spoof {
    meta:
        description = "Detects PHPMailer spoofing DocuSign via unaligned reply-to domains"
        author = "Threat Intel Blog"
        severity = "High"
    strings:
        $hdr_from = "From: " ascii wide nocase
        $target_brand = "docusign.com" ascii wide nocase
        $mailer = "X-Mailer: PHPMailer" ascii wide nocase
        $reply_top = /Reply-To:.*@[a-z0-9\-]+\.top/ ascii wide nocase
    condition:
        all of ($hdr_*) and $target_brand and $mailer and $reply_top
}

Treat email headers as forensic evidence, not metadata summaries. Extracting the underlying infrastructure from the bottom of the Received: chain gives you indicators that outlive a single phishing domain or subject line.

Want a second set of eyes on your security posture?

Let's talk about where your real exposure is.

Book an advisory call