Injecting spoofed headers with email relaying involves manipulating the email headers to disguise the true origin of an email, making it appear as if it was sent from a legitimate source. Here’s a detailed explanation of how this process works:

1. Understanding Email Headers

Email headers contain vital information about the sender, recipient, and the path an email takes from the source to the destination. Key headers include:

• From: The email address of the sender.
• To: The recipient’s email address.
• Subject: The subject line of the email.
• Received: Information about the mail servers that handled the email as it traveled from sender to recipient.
• Return-Path: The email address where bounces and error messages should be sent.

2. Email Relaying

Email relaying is the process of sending an email from one server to another. This is typically done by SMTP (Simple Mail Transfer Protocol) servers. Normally, email servers are configured to relay emails only from authenticated users to prevent abuse by spammers.

3. Spoofing Headers

Spoofing email headers involves altering the email headers to misrepresent the email’s source. This can be done for various malicious purposes, such as phishing, spreading malware, or bypassing spam filters. Here’s how it can be done:

a. Crafting the Spoofed Email

An attacker can use various tools and scripts to create an email with forged headers. They might use a command-line tool like sendmail, mailx, or a programming language with email-sending capabilities (e.g., Python’s smtplib).

b. Setting Up an Open Relay

An open relay is an SMTP server configured to accept and forward email from any sender to any recipient. Attackers look for misconfigured servers on the internet to use as open relays.

c. Injecting Spoofed Headers

The attacker crafts an email with forged headers, such as a fake “From” address, and sends it through an open relay. The open relay server processes the email and forwards it to the recipient’s server without verifying the authenticity of the headers.

d. Delivery to Recipient

The recipient’s email server receives the email and, based on the spoofed headers, believes it to be from a legitimate source. This can trick the recipient into trusting the email’s content.

4. Example of Spoofing Email Headers

Here’s an example using Python’s smtplib to send an email with spoofed headers:

import smtplib
from email.mime.text import MIMEText

# Crafting the email
msg = MIMEText("This is the body of the email")
msg['Subject'] = 'Spoofed Email'
msg['From'] = 'spoofed.sender@example.com'
msg['To'] = 'recipient@example.com'

# Sending the email via an open relay
smtp_server = 'open.relay.server.com'
smtp_port = 25

with smtplib.SMTP(smtp_server, smtp_port) as server:
    server.sendmail(msg['From'], [msg['To']], msg.as_string())

via Frontend Transport

The statement about the term “via Frontend Transport” in header values refers to a specific configuration in Microsoft Exchange Server that could suggest a misconfiguration allowing email relaying without proper verification. Let’s break down the key elements of this explanation:

1. Frontend Transport in Exchange

In Microsoft Exchange Server, the Frontend Transport service is responsible for handling client connections and email traffic from the internet. It acts as a gateway, receiving emails from external sources and forwarding them to the internal network.

2. Email Relaying

Email relaying is the process of forwarding an email from one server to another, eventually delivering it to the final recipient. While this is a standard part of the SMTP protocol, it becomes problematic if a server is configured to relay emails without proper authentication or validation.

3. The Term “via Frontend Transport”

When email headers include the term “via Frontend Transport”, it indicates that the email passed through the Frontend Transport service of an Exchange server. This can be seen in the Received headers of the email, showing the path it took through various servers.

4. Suggestion of Blind Email Relaying

The concern arises when these headers suggest that Exchange is configured to relay emails without altering them or without proper checks. This could imply that:

• The Exchange server is not adequately verifying the sender’s authenticity.
• The server might be forwarding emails without checking if they come from trusted sources.
• Such a configuration can be indicative of an open relay, where the server forwards any email it receives, which is highly vulnerable to abuse.

5. Abuses of Open Relays

Open relays are notorious for being exploited by spammers and malicious actors because they can be used to send large volumes of unsolicited emails while obscuring the true origin of the message. This makes it difficult to trace back to the actual sender and can cause the relay server’s IP address to be blacklisted.

Here’s a detailed breakdown of the key points:

Scenario Breakdown

1. Attackers Use a Genuine Microsoft Office 365 Account
   • The attackers have managed to send an email from a genuine Microsoft Office 365 account. This could be through compromising an account or using a trial account.
2. Email Branded as Disney
   • The email is branded as coming from Disney (disney.com). This branding could involve setting the “From” address to appear as if it’s from a Disney domain, which can trick recipients into believing the email is legitimate.
3. Gmail’s Handling of Outlook’s Servers
   • Gmail has robust mechanisms to handle high volumes of emails from trusted servers like Outlook’s (Microsoft’s email service). These servers are built to send millions of emails per hour, so Gmail will not block them due to rate limits.
4. SPF (Sender Policy Framework)
   • SPF is a protocol that helps prevent email spoofing by allowing domain owners to specify which mail servers are authorized to send emails on their behalf. The attackers benefit from this because:
     • The email is sent through Microsoft’s official relay server, protection.outlook.com.Disney’s SPF record includes spf.protection.outlook.com, which means emails sent through this relay server are authorized by Disney’s domain.
     .
5. Spoofed Headers
   • Spoofed headers involve altering the email headers to make the email appear as if it originated from a different source. In this scenario, the attackers have spoofed headers to make the email look like it’s from Disney.
6. SPF Check Passed
   • Since the email is sent via a server included in Disney’s SPF record (protection.outlook.com), it will pass the SPF check, making it seem legitimate to the recipient’s email server.

DKIM (DomainKeys Identified Mail)

DKIM is another email authentication method that allows the receiver to check if an email claiming to come from a specific domain was indeed authorized by the owner of that domain. This is done by verifying a digital signature added to the email.

Points of Concern

• SPF Check Passed
  • The email passed the SPF check because it was sent through an authorized server (protection.outlook.com) included in Disney’s SPF record.
• Spoofed Headers
  • The headers were manipulated to make the email appear as if it came from Disney, which can deceive recipients.
• Gmail Handling
  • Gmail will trust and not rate-limit emails from Outlook’s servers, ensuring the email is delivered without being flagged as suspicious due to high sending volumes.

Potential for DKIM

To fully understand if the email can pass DKIM checks, we would need to know if the attackers can sign the email with a valid DKIM key. If they manage to:

• DKIM Alignment
  • Ensure the DKIM signature aligns with the domain in the “From” header (disney.com).
• Valid DKIM Signature
  • Use a valid DKIM signature from an authorized domain (which would be difficult unless they have compromised Disney’s signing keys or a legitimate sending infrastructure).

Proofpoint and similar services are email security solutions that offer various features to protect organizations from email-based threats, such as phishing, malware, and spam. They act as intermediaries between the sender and recipient, filtering and relaying emails. However, misconfigurations or overly permissive settings in these services can be exploited by attackers. Here’s an explanation of how these services work, their roles, and how they can be exploited:

Roles and Features of Proofpoint-like Services

1. Email Filtering and Protection
   • Spam and Phishing Detection: Filters out spam and phishing emails.
   • Malware Protection: Scans and blocks emails containing malware or malicious attachments.
   • Content Filtering: Enforces policies on email content, attachments, and links.
2. Email Relay and Delivery
   • Inbound and Outbound Filtering: Manages and filters both incoming and outgoing emails to ensure compliance and security.
   • Email Routing: Directs emails to the appropriate recipients within an organization.
   • DKIM Signing: Adds DKIM signatures to outgoing emails to authenticate them.
3. Authentication and Authorization
   • IP-Based Authentication: Uses IP addresses to authenticate incoming email servers.
   • SPF, DKIM, and DMARC Support: Implements these email authentication protocols to prevent spoofing.

How Misconfigurations Allow Exploitation

1. Permissive IP-Based Authentication
   • Generic Configuration: Proofpoint is often configured to accept emails from entire IP ranges associated with services like Office365 or Google Workspace without specifying particular accounts.
   • IP Range Acceptance: Once a service like Office365 is enabled, Proofpoint accepts emails from any IP within the Office365 range, regardless of the specific account.
2. Exploitation StepsStep 1: Setting Up the Attack
   • Attacker’s Office365 Account: The attacker sets up or compromises an Office365 account.
   • Spoofing Email Headers: The attacker crafts an email with headers that mimic a legitimate sender, such as Disney.
   Step 2: Leveraging Proofpoint Configuration
   • Sending Spoofed Emails: The attacker sends the spoofed email from their Office365 account.
   • Proofpoint Relay Acceptance: Proofpoint’s permissive configuration accepts the email based on the IP range, without verifying the specific account.
   Step 3: Proofpoint Processing
   • DKIM Signing: Proofpoint processes the email, applying DKIM signatures and ensuring it passes SPF checks because it comes from an authorized IP range.
   • Email Delivery: The email is then delivered to the target’s inbox, appearing legitimate due to the DKIM signature and SPF alignment.

Example of a Permissive Configuration in Proofpoint

1. Admin Setup
   • Adding Hosted Services: Proofpoint allows administrators to add hosted email services (e.g., Office365) with a single-click configuration that relies on IP-based authentication.
2. No Specific Account Configuration
   • Generic Acceptance: The setup does not specify which particular accounts are authorized, leading to a scenario where any account within the IP range is accepted.
3. Exploitation of Misconfiguration
   • Blind Relay: Due to this broad acceptance, attackers can send emails through Proofpoint’s relay, which then processes and delivers them as if they were legitimate.

A recent attack exploited a misconfiguration in Proofpoint’s email routing, allowing millions of spoofed phishing emails to be sent from legitimate domains like Disney and IBM. The attackers used Microsoft 365 tenants to relay emails through Proofpoint, bypassing SPF and DKIM checks, which authenticate emails. This “EchoSpoofing” method capitalized on Proofpoint’s broad IP-based acceptance of Office365 emails. Proofpoint has since implemented stricter configurations to prevent such abuses, emphasizing the need for vigilant security practices.

For more details, visit https://labs.guard.io/echospoofing-a-massive-phishing-campaign-exploiting-proofpoints-email-protection-to-dispatch-3dd6b5417db6

The Domain Name System: Understand Why Domain Name Is Still Relevant

How to Catch a Phish: A Practical Guide to Detecting Phishing Emails 

Step-by-step instructions on what to do if you fall prey to this type of cyber crime.  (Phishing in 2024)

InfoSec services | InfoSec books | Follow our blog | DISC llc is listed on The vCISO Directory | ISO 27k Chat bot

Tags: EchoSpoofing, trusted domains