R
RossAdams
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 actions—such 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:
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 ways—either 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:
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 appropriately. Defender 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:
Continue reading...
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 actions—such 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 ways—either 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:
- 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.
- 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 appropriately. Defender 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:
- Learn more about the recent EchoSpoofing attack.
- Check out our website to learn more about Defender for Office 365.
- Not a customer, yet? Start a free trial today.
Continue reading...