Since 7/3/2024. we have received a series of attacks that follow this server sequence:
(The attacks are of the type "I want to send you money.")
Upon receipt,
Outlook.com adds "X-MS-Exchange-Authentication-Results" and "Received-SPF" headers indicating that the MailFrom and From domains match, and that SPF did not validate. Three different identities have been used. Depending on the identity being impersonated, the Received-SPF result is correctly reported as Fail, SoftFail, or None, but the message is accepted anyway.
The message is apparently sent to
dsdepr.onmicrosoft.com and then forwarded to a distribution list, because
Outlook.com adds a dkim-signature for domain
dsdepr.onmicrosoft.com. It also adds an ARC Set showing the original Mail From and message From addresses. The ARC Set also reports a value for smtp.rcpttodomain, but the values are random. Apparently they report one of the after-forwarding recipient domains, not the initial recipient, because the values includes domains that are not hosted on Outlook.com. So that element of the ARC set is misleading and not consistent with the design behind the ARC Specifcation.
Somewhere in this process, the Mail From address is rewritten to
@salud.pr.gov">bounce+<random>@salud.pr.gov, which ensures that the final recipient detects SPF PASS. As I write this,
salud.pr.gov a DMARC policy of quarantine. As recently as yesterday, I am pretty sure it had no DMARC policy.
Defenses:
You can start by blocking messages from
salud.pr.gov or by enforcing DMARC to take advantage of the new DMARC policy. That will protect against impersonation of this victim, but does not prevent the attacker from switching to a different victim.
Within SmarterMail, you could create a custom rule for header DKIM-SIGNATURE contains dsdepr.onmicrosoft.com, but this will create a bounce message. In this example,
salud.pr.gov passed SPF , so the bounce message will go to the victim, which illustrates why I don't send any bounce messages. (SmarterMail spam defenses need to provide more ways to block during Inbound SMTP, so that the messages can be rejected without generating a bounce message.)
Within DECLUDE you could create a custom rule for HEADER PCRE that includes both the header name and the dsdepr name. This could be used with a DELETE action to silently discard the attack.
In a perfect world,
Outlook.com would not allow SPF Upgrade attacks like this.
Longer term, I am trying to figure out how to parse the message header to tell whether a message has been forwarded or not, and whether the forward is acceptable. Some people have assured me that this is a fools errand, and examples like this show that it will be difficult. But I am continuing to try.