Forum Discussion
Bad actors impersonating Microsoft Billing using rogue on-prem. Exchange > M365 tenants
Everyone should be aware and watch out for these very believable spoofs coming from microsoft-noreply_at_microsoft.com.
If you have Threat Explorer (Defender Portal > Email & Collaboration > Explorer) or Advanced Hunting (EmailEvents table) available, you can find these messages by looking for these criteria:
- Sender From Address: microsoft-noreply_at_microsoft.com (note the @ / _at_ swap)
- Sender MailFrom Domain: Not equal to Microsoft.com (will be <something>.onmicrosoft.com)
If you're getting these, you'll notice the MailFrom domain is an ever-changing long list of rogue tenants (e.g., <rogueTenant123>.onmicrosoft.com). The MailFrom address will be starting with "bounces+srs", like this "bounces+srs=<12345567890abcxyz>@<rogueTenant123>.onmicrosoft.com", letting us see that these bad actors are using an on-premises Exchange server, SMTP receive Connector and then a Send Connector up to and out via EXO/EOP.
These things pass SPF, DKIM, and DMARC and so only get detected via General/Advanced filter and/or Fingerprint Matching (which only means loose match, there's no specific fingerprint/ID involved).
The subject seems to always be "Your Microsoft order on September 23, 2024", and will be for the current date.
Some people have raised this on Reddit, for example: email address removed for privacy reasons - Suspicious email : r/DefenderATP (reddit.com)
I've been working with MS Support to try and get this addressed. We're seeing a lot of these, and so far it's be many many different rogue tenants, so it seems like the bad actors are working overtime and successfully standing up tenant after tenant to get these things out successfully.
1 Reply
- FYI, this attack technique is now being used to successfully spoof DocuSign.net senders. They're using very commonly used DocuSign sender addresses, have the mail from/return-path using the Sender Rewrite Scheme format of bounces+SRS=12345abcde@<compromised-tenant>.onmicrosoft.com.
I'm not sure if the entire tenant and on-premises Exchange are being stood up as fake legit tenants and then used purely for this, or if it is unknowing legitimate customers' on-premises Exchange being abused without them knowing. The tenant names look legitimate, sort of maybe / hard to tell.
But this technique is letting people spoof both Microsoft.com and DocuSign.net and pass DMARC, DKIM, somehow. Unable to fathom exactly how EOP is passing DKIM/DMARC other than that I think MS' implementation of ARC is being taken advantage of, and earlier DKIM passes are being observed in the headers, then faultily leading to final DMARC pass. Something like that.
The best way I have seen to stop these messages is to just use a Transport Rule. TABL is not good enough! We need these 2 conditions:
Microsoft spoofs:
1.) Sender address is email address removed for privacy reasons
2.) Return-Path header contains word "onmicrosoft.com"
DocuSign.net spoofs:
1.) Sender domain is DocuSign.net
2.) Return-path header contains word "onmicrosoft.com"
Then either block/quarantine, increase SCL - do whatever is your preferred approach. These are rather broad criteria so I would advise Quarantine at most to start just to be able to observe and be sure not to impact the legitimate emails from these 2 sources.
