Multiple From Headers

This attack exploits inconsistencies in how email clients and servers handle multiple From headers in a single email message. By including multiple From headers with different sender addresses, attackers can cause different systems to display different senders for the same email.

Attack Summary: Exploiting inconsistent handling of multiple From headers to create emails that appear to be from different senders depending on the email client or server.

Background: Email Headers

According to RFC 5322, an email message should have only one From header. However, many email clients and servers do not strictly enforce this requirement, leading to inconsistent behavior when multiple From headers are present.

From: legitimate@example.com From: attacker@malicious.com Subject: Important Information Email content here...

Different email clients may display either the first From header, the last From header, or even show an error or warning. This inconsistency creates opportunities for attackers to manipulate how their emails are displayed to recipients.

Attack Methodology

This attack involves sending emails with multiple From headers to exploit inconsistencies in how different systems process these headers.

Basic Multiple From Attack

Exploiting inconsistent header processing

The most basic form of this attack involves sending an email with two different From headers.

Attack Example

Email with multiple From headers

HELO attacker.com MAIL FROM: <attacker@malicious.com> RCPT TO: <victim@victim.com> DATA From: <ceo@company.com> From: <attacker@malicious.com> To: <victim@victim.com> Subject: Urgent Action Required Dear Employee, Please review the attached document and respond immediately. .

Explanation: In this example, the attacker sends an email with two From headers. Some email clients will display the first From header (ceo@company.com), while others will display the second From header (attacker@malicious.com). This inconsistency can be exploited to make the email appear to be from the CEO to some recipients.

How It Works

Attacker creates an email with multiple From headers
The email is sent to the victim's email server
Different email clients process the headers differently
Some clients display the first From header, others display the last
The inconsistency creates confusion about the actual sender
Recipients may trust the email if they see a trusted sender address

Client-Specific Targeting

Exploiting known client behaviors

Attackers can target specific email clients by knowing how they handle multiple From headers.

Client-Specific Attack

Targeting specific email clients

HELO attacker.com MAIL FROM: <attacker@malicious.com> RCPT TO: <victim@victim.com> DATA From: <security@bank.com> From: <newsletter@bank.com> From: <attacker@malicious.com> To: <victim@victim.com> Subject: Security Alert Dear Customer, We have detected suspicious activity on your account. Please log in immediately. .

Explanation: This example includes three From headers. The attacker knows that Client A displays the first header, Client B displays the second header, and Client C displays the last header. By structuring the headers in this way, the attacker can target users of specific email clients with different sender identities.

Client Behavior Examples

Outlook: Typically displays the first From header
Gmail: May display the last From header or mark the email as suspicious
Apple Mail: May display the first From header or combine multiple headers
Thunderbird: Often displays the last From header
Mobile clients: Vary widely in their handling of multiple headers

Authentication Bypass

Bypassing email authentication mechanisms

Multiple From headers can sometimes be used to bypass email authentication mechanisms like SPF, DKIM, and DMARC.

Authentication Bypass Example

Bypassing email authentication

HELO attacker.com MAIL FROM: <legitimate@example.com> RCPT TO: <victim@victim.com> DATA From: <legitimate@example.com> From: <ceo@target.com> To: <victim@victim.com> Subject: Confidential Information Please review the attached confidential document. .

Explanation: In this example, the attacker uses a legitimate domain in the MAIL FROM and first From header that they can authenticate with SPF/DKIM. The second From header contains the spoofed address. Some email clients will display the spoofed address while the email passes authentication checks because the authentication mechanisms check against the MAIL FROM address or the first From header.

Authentication Implications

The impact on authentication mechanisms depends on how they are implemented:

SPF: Checks the MAIL FROM address, not the From header
DKIM: Signs headers, but may not detect multiple instances of the same header
DMARC: Alignment checks may use only one of the From headers
Anti-spam filters: May have inconsistent handling of multiple headers

Impact

This attack allows attackers to:

Create confusion about the actual sender of an email
Bypass email authentication mechanisms in some cases
Target specific email clients with tailored spoofing techniques
Conduct sophisticated phishing attacks that appear legitimate to some recipients

Detection

Organizations can detect these attacks by:

Implementing email security solutions that check for multiple instances of the same header
Configuring email gateways to reject or quarantine emails with multiple From headers
Using email clients that warn users when multiple From headers are detected
Training users to be suspicious of emails with inconsistent sender information

Mitigation

To protect against these attacks, organizations should:

Reject multiple headers: Configure email servers to reject messages with multiple From headers
Implement strict parsing: Use email security solutions that strictly enforce RFC standards
Use header canonicalization: Implement DKIM with strict header canonicalization
Deploy advanced filtering: Use email security gateways with advanced header analysis
User education: Train users to recognize signs of email spoofing and phishing

Testing

Security professionals can test for this vulnerability using the following approach:

Create test emails with multiple From headers
Send these emails to test accounts using different email clients
Observe how different clients display the sender information
Check if email authentication mechanisms detect or block the emails
Document inconsistencies in how different systems handle the emails

References

RFC 5322: "Internet Message Format." https://tools.ietf.org/html/rfc5322
Chen, J., Duan, H., Weaver, N., Paxson, V., & Jiang, J. (2021). "Measuring and Mitigating Email Sender Spoofing Attacks." In Proceedings of the 30th USENIX Security Symposium.
Foster, I. D., Larson, J., Masich, M., Snoeren, A. C., Savage, S., & Levchenko, K. (2015). "Security by Any Other Name: On the Effectiveness of Provider Based Email Security." In Proceedings of the 22nd ACM SIGSAC Conference on Computer and Communications Security.
Hu, H., Peng, P., & Wang, G. (2018). "Characterizing Pixel Tracking through the Lens of Disposable Email Services." In Proceedings of the 2018 IEEE Symposium on Security and Privacy (SP).

Previous: Authentication Results Injection Next: From/Sender Ambiguity