Office 365 Phishing Emails Epidemic
Posted by mickeykarimzadeh@reddit | sysadmin | View on Reddit | 35 comments
We have quite a few Office 365 tenants over the last week complaining about phishing emails being delivered to mailboxes appearing to come from the user that received it, with either a password reset link, a voicemail link etc. Users with E3/Defender/etc. are not immune. I have a ticket open with Sherweb, and a ticket open directly with MS and it's not going anywhere. These are messages that show a SPF fail and a DMARC fail in the header, but there is a CompAuth pass with reason 703. There is something going on with the Office 365 filters, and I don't know what to do.
Mrgurth1@reddit
Give me 20 minutes ill be home and can get you a rule that I made that stopped them today
BoltActionRifleman@reddit
42 minutes
Mrgurth1@reddit
Its live 😎 refresh page
BoltActionRifleman@reddit
You should write documentation, this is some most excellent step by step!
Mrgurth1@reddit
Lol, it’s definitely got a few spelling mistakes and some unfinished sentences. Reddit isn’t letting me go back and edit it for some reason. But thanks, I appreciate that. I think my boss would agree with you too. The documentation I create at work follows the same level of detail.
To me, documentation should be clear enough that someone with little to no IT experience can follow it without getting stuck. I really don’t like the mindset of “I am the documentation. It’s my job security.” That approach just makes things harder on your team, and if something ever happens to you, they’re left scrambling and probably frustrated or even resent you for it.
Mrgurth1@reddit
Okay, Okay sorry for the delay on getting this out to everyone I wanted to be thorough.
I dont know everyone's skill or expertise so I'm going to explain it like I would to someone who's never touched exchange.
Go to Exchange Admin Portal > Mail Flow (drop down) > Rules (option on drop down) > Add a Rule > Create a new rule
Apply this rule if.. Select "The message headers..."
2a. Then where it says "select one" click drop down. Select "Includes any of these words"
2b. Click the blue text that says "enter text" on the left. Enter "Authentication-Results" but without the quotes and click "Save" at the bottom.
2c: Next click the second blue text "enter words" once again you'll be prompted to add text. You'll enter " spf=fail" but without the quotes. Click add then click save.
To the right of "Apply this rule if" you will see a + icon click this to add another "apply this rule if" line. (You'll then see the new line has And at the top of it. This is adding an additional condition for the rule.)
3a. Set the first drop down to "the sender" and the second drop down to "domain is"
3b. This is pop-up a new window. Enter all your domains you own. for example: test123.com then click "add" then Save at the bottom.
again we're going to click the + icon at the top to add another row. Once you click it you'll see another condition with and above it.
4a. first drop down select "the message headers..." The second drop down select "matches these text patterns.
4b. Click the blue text that says "enter text" on the left. Enter "Received-SPF" but without the quotes and click "Save" at the bottom.
4c. Next click the second blue text "enter words" once again you'll be prompted to add text. You'll enter " helo=\[127\.0\.0\.1\]" but without the quotes. Click add then click save.
NOTE: I know the text is odd but this is regex update to look for specifically "127.0.0.1" which is local host and is in every spoof email you've received and the way it is formatted has meaning trust the process. I'll let you chatgpt it if you want more info can be
Now click on the drop down for "Do the following"
5a. first drop down click "forward the message for approval" second drop down click "to these people"
5b. Now enter the admins you want to approve these emails.
For settings tab at the top
6a. Set priority to #1 so it is the first rule every email goes through.
6b. Rule mode Set to "enforce"
6c. Severity set to "high"
6d. at the bottom set "match sender address in message" to "header"
BOOM you're done his save on that bad boy and be the IT hero.
NOTE: this is a temporary thing.. Once you've let this run for a week and nothing is getting stomped on internally you can change the last "do the following" to delete the email or send to quarantine.
NOTE 2: If something is getting stomped on.. no biggie.. approve it and it will be sent to the email / distro it was supposed to. then just add an additional condition to allow it through. but I'm 99.999% sure this will take care of everyone.
I'm including an image of what this should look like when done.
cashew76@reddit
After adding the rule - enable the rule. Disabled by default. :/
Mrgurth1@reddit
Great catch! I'll get that added!
Mrgurth1@reddit
Here is an image to help
hkusp45css@reddit
You're a fucking hero for doing that.
I mean it. That's a great walk through with timely and relevant information formatted and delivered so just about any who could access the UX could follow.
Bravo. Really well done.
Mrgurth1@reddit
No biggie at all! This sub has saved my butt many times over the years so about time I do my part.
TheUnrepententLurker@reddit
You're a hero of the federation
zerolagaux@reddit
Is this if you don't disable direct send completely or in addition?
Mrgurth1@reddit
Yes, this would be for people that still have to have direct send enabled for their tenant (be it for some legacy nonsense that requires it). We do have until Jan 2027 to get something inplace so you still have time before SMTP is required.
Ill-Mail-1210@reddit
I’m interested in the rule, we haven’t seen this but I want to be a little proactive for my clients
Mrgurth1@reddit
Its up now :) thanks for your patience
drparton21@reddit
Well, that's going to make my weekend a bit less of a headache.
Mrgurth1@reddit
Its live refresh
bsmaws@reddit
It’s been 29 mins….we’re still waiting 😂
Mrgurth1@reddit
Almost done
adammerkley@reddit
Following
CryptographerAlive13@reddit
If the issue is direct send, you might need to work on your threat intelligence. This is not news and I'm still shocked when I see people ask about it today.
m4tic@reddit
If you set up these tenants a while back, your receive connectors do not have ip restrictions on them. That means anyone can send to your non-published (bypass mx record) default connector by guessing the hostname based on the email domain.
Begmypard@reddit
Disable direct send on the o365 tenant, this has been an ongoing vector of attack for some time.
SubNine5@reddit
Get-OrganizationConfig | Select-Object Identity, RejectDirectSend
If false direct sends gets through.
lechango@reddit
Yep, just make sure have connectors setup for anything that needs to legitimately direct-send.
virtualuman@reddit
Very odd that Microsoft isn't providing you with the articles to follow and resolve.
shokzee@reddit
CompAuth reason 703 means Microsoft's composite authentication decided the message was legit despite SPF and DKIM failing. That's their "implicit authentication" overriding your actual email auth results, which is infuriating when it lets obvious phish through.
Set your DMARC policy to p=reject if you haven't already, but the real problem is that EOP sometimes trusts its own signals over DMARC. You can create a mail flow rule that quarantines messages where the sender's domain is your own AND the SCL is >= 1, or use the "antispoofing" settings in Defender to be more aggressive. Also check your tenant's spoof intelligence page, Microsoft might be explicitly allowing these senders.
We see this with our clients all the time. Microsoft's built-in filtering has blind spots with self-to-self spoofing. We switched our clients to Suped for the monitoring side so we can actually see when DMARC-failing mail is getting delivered instead of relying on MS to tell us something's wrong.
terminal-admin@reddit
I was getting these but it was because our DMARC was set to do nothing. I changed it to quarantine. There is a default defender anti phishing rule that will move these to quarantine if dmarc=quarantine.
Seems to be working fine now. No new emails reported.
edmozley@reddit
Lock direct send down to your office ip - https://techcommunity.microsoft.com/blog/exchange/introducing-more-control-over-direct-send-in-exchange-online/4408790
NotABadPirate@reddit
I disabled direct send on about 15 clients. A mix of Microsoft tenants and Godaddy federated tenants. One—only one, Godaddy tenant could not send inside their domain (Joe@domain to Sally@domain) I had to re-enable it. I'm still trying to understand what broke when I disabled direct send for this one domain.
Full-Independence-54@reddit
Happening in my org too. My COO got hoodwinked by one.
nbritton5791@reddit
Seeing it too.
Not sure why it's just now becoming an issue for us in the last 72h. Feels like a renewed attack campaign.
Analysis of headers reveals it's not cross tenant and doesn't appear to be direct send.
Absurd that Microsoft is letting these through without defender touching them. I've submitted them for analysis, and then Microsoft goes "oh, yep, that's definitely bad!" Thanks.... after the fact.
ZoneEmbarrassed7697@reddit
Direct send.
selfdeprecafun@reddit
Probably direct send. Check headers for the keywords cross tenant. Disabled direct send for your tenant and use connectors for anything that needs to directly hit your mx record.