Header Manipulation
This attack involves manipulating email headers to bypass authentication mechanisms and create convincing spoofed emails.
Attack Summary: Manipulating email headers to bypass authentication and create convincing spoofed emails.
Background: Email Headers
Email headers contain metadata about the email, including information about the sender, recipient, subject, and routing. Headers are added by various systems as the email travels from the sender to the recipient.
Common email headers include:
- From: The sender's email address
- To: The recipient's email address
- Subject: The subject of the email
- Date: The date and time the email was sent
- Message-ID: A unique identifier for the email
- Received: Information about the servers that handled the email
- Return-Path: The return address for bounces
- Reply-To: The address that replies should be sent to
Email headers can be manipulated by attackers to bypass authentication mechanisms and create convincing spoofed emails.
Attack Methodology
This attack involves manipulating various email headers to bypass authentication mechanisms and create convincing spoofed emails.
This variant involves manipulating the From header to make the email appear to come from a trusted sender.
From Header Example
Manipulating the From header
From vs. MAIL FROM
There are two different "from" addresses in an email:
- MAIL FROM: The envelope sender, used for routing and bounce messages
- From: The header sender, displayed to the recipient
These addresses can be different, and many email authentication mechanisms only check one or the other.
This variant involves manipulating the Reply-To header to redirect replies to the attacker.
Reply-To Header Example
Manipulating the Reply-To header
Reply-To Attacks
Reply-To attacks can be used for various purposes:
- Conversation hijacking: Redirecting replies to the attacker
- Data theft: Capturing sensitive information in replies
- Social engineering: Building trust through ongoing communication
- Bypassing security: Some security systems don't check the Reply-To header
This variant involves manipulating Received headers to make the email appear to have passed through legitimate servers.
Received Header Example
Manipulating Received headers
Received Header Analysis
Received headers are added by each server that handles the email, in reverse chronological order:
- Top header: Added by the most recent server
- Bottom header: Added by the first server
Attackers can add fake headers at the bottom to make it appear that the email originated from a legitimate server.
Impact
This attack allows attackers to:
- Bypass email authentication mechanisms
- Create convincing spoofed emails
- Redirect replies to attacker-controlled addresses
- Make emails appear to have passed through legitimate servers
- Conduct more effective phishing and business email compromise attacks
Detection
Organizations can detect these attacks by:
- Implementing email authentication mechanisms (SPF, DKIM, DMARC)
- Checking for inconsistencies between envelope and header addresses
- Analyzing Received headers for anomalies
- Monitoring for suspicious Reply-To addresses
- Using email security solutions that check for header manipulation
Mitigation
To protect against these attacks, organizations should:
- Implement authentication: Use SPF, DKIM, and DMARC for all domains
- Check headers: Verify that envelope and header addresses match
- Validate Received headers: Check that Received headers form a logical chain
- Monitor Reply-To: Check for suspicious Reply-To addresses
- Train users: Educate users about the risks of email spoofing and phishing
- Use email security: Implement email security solutions that check for header manipulation
Testing
Security professionals can test for this vulnerability using the following approach:
- Send test emails with various header manipulations
- Check if the emails bypass authentication mechanisms
- Check if the emails appear legitimate to recipients
- Document the results and recommend appropriate mitigations
References
- RFC 5322: "Internet Message Format." https://tools.ietf.org/html/rfc5322
- RFC 7208: "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email." https://tools.ietf.org/html/rfc7208
- RFC 6376: "DomainKeys Identified Mail (DKIM) Signatures." https://tools.ietf.org/html/rfc6376
- RFC 7489: "Domain-based Message Authentication, Reporting, and Conformance (DMARC)." https://tools.ietf.org/html/rfc7489