Blog Post

Microsoft Defender for Office 365 Blog
4 MIN READ

Secure architecture design – How Defender for Office 365 protects against EchoSpoofing

RossAdams's avatar
RossAdams
Icon for Microsoft rankMicrosoft
Aug 22, 2024

A new spoofing technique labeled “EchoSpoofing” was recently reported that impacted select Proofpoint customers. This blog provides a brief overview of how this particular attack exploited their specific architecture and describes the architecture best practices implemented by Microsoft Defender for Office 365 that protect against EchoSpoofing and spoofing attacks broadly.

 

What is “Spoofing”?

Spoofing is a tactic used by threat actors to disguise their identity by manipulating data, such as the email sender address, to appear as a trusted source through impersonation. The goal of this technique is typically to deceive individuals or systems into taking actionssuch as divulging sensitive information, gaining unauthorized access, or executing financial transactions.

 

When a From address is spoofed, the user will see what appears to be a legitimate email address, such as user@contoso.com. But in reality, the message did not come from contoso.com, based on the information contained in the headers of the message. Protecting this visible address is important, as it helps users trust the information they see.

 

 

As a first line of defense, users need to be able to trust the visible information in the From address and validate that it really is the person who sent the message. To do this, email providers use various standards to validate the From address to protect it from being spoofed, including:

 

  • Sender Policy Framework (SPF) – An email authentication standard that helps protect senders and recipients from spam, spoofing, and phishing. By adding an SPF record to your Domain Name System, you can provide a public list of senders that are approved to send email from your domain.
  • DomainKeys Identified Mail (DKIM) – An email authentication standard that adds a digital signature to outgoing messages. Mail servers receiving messages signed with DKIM can verify messages truly came from the sender, and not someone impersonating the sender.
  • Domain-based Message Authentication Reporting & Conformance (DMARC) – An email security standard which verifies the email sender by building on the DKIM and SPF protocols in DNS.

 

Defender for Office 365 uses all these technologies and more, including Spoof intelligence to provide effective protection against spoofing and Authenticated Received Chain (ARC) to preserve original authentication details from third-party email services, which may sit in front of Microsoft 365. If you are using another vendor, check with them for support.

 

What is EchoSpoofing?

“EchoSpoofing” is a process that allowed a bad actor to spoof the From address of certain domains by relaying a message through different services. A weakness in Proofpoint’s architecture enabled modifiable email routing configuration on Proofpoint servers to allow relay of organizations’ outbound messages through their services. Attackers exploited this to bypass email authentication checks when the message was relayed. This resulted in their messages being updated so that authentication would pass at the receiving service and appearing as trusted.

 

There are common use cases for relaying messages, such as forwarding. But in this case the validity of the sender was not verified before the message was accepted and relayed. Additionally In a shared environment, validation of the sender is critical to avoid these types of problems.

 

 

THe Defender for Office 365 secure architecture is designed to protect against EchoSpoofing

In Microsoft Defender for Office 365, you can send messages in various wayseither direct to an SMTP endpoint or via connectors. In both cases, Microsoft validates the sender of the message to ensure we process the message correctly or simply reject it as an invalid relay.

In each case, the sender is validated and the message is attributed to a tenant as follows:

 

  1. Inbound Connectors If a message comes in via an inbound connector, the SMTP.MailFrom (P1) sender or the certificate on the connector is used to validate the connection to the specific tenant. If no attribution can be made, the connection is handled just like an incoming internet connection.
  2. Internet Connections – Messages that are received from the internet are considered to be incoming and processed as such.

The image below shows the flow of traffic and what would happen if the same attack was attempted in environments where organizations are using Defender for Office 365 to protect their email.

 

In the diagram above, even though the message is directed to the Fabrikam.com tenants’ endpoint, it will be treated as internet traffic and handled as generic incoming traffic—meaning the message would be considered incoming to the Alpineskihouse.com tenant from user@fabrikam.com. Since the From address cannot be validated based on the data in the message due to the lack of alignment between the P1 sender and the DKIM domain, it would be considered spoof and handled appropriatelyDefender for Office 365 effectively will not allow the attacker to cleanse the message by trying to pass it through the Fabrikam tenant, negating the EchoSpoofing attack.

 

In Microsoft Defender for Office 365 all of these protections are enabled by default and inherent to our architecture design. There is no configuration requirement for customers.

 

 

More information:

Updated Aug 22, 2024
Version 2.0
  • Hi RossAdams,

    are you sure that this setting is enable for EVERY destination email address into alpineskihouse.com domain?

    Everything you say is true if the recipient address (TO) is a mailbox. If it is a distribution list with external contacts or there are external redirects in the mailboxes, it is not true.

     

    There is also a much more serious vulnerability to consider: Spoofing vulnerability in Exchange Online | LinkedIn

    Unfortunately.

     

    We still have a long way to go to fully comply with the DMARC protocol.

    Bye.

    Raffaele

  • Thanks for the feedback. We made recent changes to handling forwarding and I'm reviewing that further with the team to confirm.

  • Christophe_Dary's avatar
    Christophe_Dary
    Copper Contributor

    Hi RaffaColavecchi-MVP 

    It seems to me that the redirecting issue also exists when the recipient address is a mailbox.

     

    RossAdams although it is not a relaying issue but a redirecting issue, the effect is similar to echo spoofing as if an internal address is spoofed in the Header From, then the redirect process authentify the message by applying an aligned DKIM signature.

    DMARC fail on the incoming message, but DMARC pass when it leaves the tenant after having been redirected.