Microsoft 365 shows internal sender, but source IP is external. How is this possible?
Posted by thmeez@reddit | sysadmin | View on Reddit | 22 comments
We had a strange case in Microsoft 365 tenant.
Someone external sent an email to an internal user, but it appeared like it came from another internal user.
What I checked:
SPF, DKIM and DMARC are already in place.
The user's Entra sign in logs look normal.
No obvious mailbox compromise.
But in Exchange Online message trace, the sender shows as the internal user, while the source IP is a different external server.
How can an attacker do this if the domain authentication records are already in place?
What should I check next, and what are the best ways to defend against this in Microsoft 365?
Hawk947@reddit
Disable direct send.
thmeez@reddit (OP)
direct send is giving access like sending from internal employee?
itsverynicehere@reddit
Direct send is taking a bad rap for MS using Compauth and allowing spoofed messages through. You need to look at the message header and see if SPF and DKIM failed but compauth= allowed the message.
The only way to solve that is to create rules to block it after the message has been "authenticated".
Hawk947@reddit
Yes. Do some searching in this sub about it. Lots of issues the last few weeks. We disabled it across all our client tenants.
thmeez@reddit (OP)
thank you very much but how do you manage service account like printers?
Hawk947@reddit
We setup exchange connectors or use printers that support auth 2.0.
1stUserEver@reddit
Authenticate with SMTP2go or licensed account.
MaNbEaRpIgSlAyA@reddit
SMTP2GO
gangaskan@reddit
Good to know..... Son of a bitch.
Is this why we have been flagged on spamhaus for about a month or so?
DavidCP94@reddit
No. Direct send only effects your internal recipients.
sc302@reddit
Technically they can use any address in your domain.
littleko@reddit
Check the DMARC policy. If you're at p=none, nothing is actually blocking the spoof, you just see it in reports.
Also verify alignment is being enforced, not just SPF/DKIM passing on some other domain in the headers. Pull the raw message and look at Authentication-Results plus the Return-Path vs From header. Classic header-from spoof works fine when DMARC isn't at quarantine or reject.
Defense in M365: move DMARC to reject, enable anti-spoof in Defender, and turn on external sender tagging so internal-looking mail from outside gets flagged.
SimpleSysadmin@reddit
This is the way
SimpleSysadmin@reddit
What’s your current dmarc policy set as? Is dkim enables? can you share the results of spf, dkim and dmarc?
silentstorm2008@reddit
The amount of orgs that have not disabled direct send is staggering. Do you have an info sec department? If not, it's stuff like this they would have pushed to get configured correctly at least a year ago.
SimpleSysadmin@reddit
Many orgs use direct send for legitimate reasons, disabling is a simple method to stop impersonations for admins who havnt setup dmarc correctly. If you care about info sec you should focus of stopping impersonation both internally and in externally with dmarc and not just using the new disable direct send option. It doesn’t hurt turning it on but admins are acting like mismatched from headers are new when it’s just because there’s been a spike and it’s hard to train all admins on fixing their policies so Microsoft developed this option
Interesting_Ad_5676@reddit
Gmail is much better than MS365
antomaa12@reddit
Check the email source code and you will find more informations. Recently we had a similar incident with someone usurpating a mail adresse from a Uzbekistan server. They were no DKIM, and DMARC in the said mail, but we still allow unautified mail sending (direct send)
discosoc@reddit
Direct Send is the normal “current” culprit making waves.
thmeez@reddit (OP)
direct send is giving access like sending from internal employee?
sc302@reddit
Anti spoofing in place? SPF dkim and dmarc all verify your domain to external hosts and “should” protect your host, but you should have anti spoofing setup too in your tenant.
JustinVerstijnen@reddit
You could check if any EXO connectors are active, this is a track that sometimes attackers use after compromise