Imagine you could easily send internal emails in M365 in the name of any person and that without authentication and from the outside, would you do it? Well, I don’t want to answer that question and I don’t want to judge you. However, I would like to show you a way to do it without any problems.
More and more organizations are moving their email infrastructure to the cloud. Whether for convenience, product lock-in, or compulsion. Many are choosing Microsoft’s Exchange Online infrastructure. All users have been migrated to Azure, the data is already in SharePoint Online, and collaboration is one of the biggest advantages of the cloud. Microsoft continues to reduce the functionality when services are not on M365. In addition, security mechanisms are already in place in the cloud that are difficult or impossible to implement on-premises. A small example is conditional access, which a midsize company cannot easily implement on its few servers. But is the security really better? clearly, yes, but not over everything and the attack surface is also clearly larger. A game with fire.
But now to the topic, any domain that you want to use in Exchange Online (EXO) needs to be set up with DNS first. It needs an A record for the MX, a TXT record for the SPF and a CNAME record for the Autodiscover service. These can be found in the M365 Admin Portal under “Settings / Domains“. Let’s take the following example, which applies to the collfuse.com domain.
What we are interested in is the MX record, as you can see this would be “collfuse-com.mail.protection.outlook.com” for us. Of course, this can also be queried from a domain with DNS lookups “nslookup “-set type=mx” collfuse.com” or, as usual with EXO, simply “guessed” because the notation is always the same [domain name]-[top-level domain].mail.protection.outlook.com.
All that is needed to fake senders, or better to send in the name of a person, are 2 real users that appear in the domain. One is the recipient address and the other is the sender address. I have already described in the blog “Azure Information Gathering” how you can find out the existence of a user.
In our fictional example, we now assume that we have a CEO named Johnny Attack ([email protected]) and a regular employee James Bons ([email protected]) in the company. So now we want to send an email on behalf of CEO Johnny to employee James, which he will perceive as internal. Normally we would need a password and MFA, right? Not in this case.
The following Powershell line, Powershell is not mandatory, does the job! As you can see, no authentication or anything like that.
Send-MailMessage -From "[email protected]" -To "[email protected]" -SmtpServer "collfuse-com.mail.protection.outlook.com" -Port 25 -Subject "Salary increase"And here how this arrives in the mailbox.
Hold on, what?? Yes, that’s right, pretty cool, isn’t it? But here’s where it gets exciting, many companies probably have an Exchange transport rule that marks external mail. For example, the subject is rewritten or a red bar is added in front of the mail body. In the Exchange Admin Portal these can be found under “Mail Flow / Rulses”. Here is an example that rewrites the subject for external senders so that the recipient can clearly see it.
That should ruin our beautiful plan, shouldn’t it? Not at all! Another mail with the same Powershell command, but this time with a different subject, shows that the rule is completely bypassed and the mail looks like an internal mail to the recipient. Oh gosh!
You can only protect yourself against this attack if authentication is enabled on the SMTP. However, this can only be done if another mail gateway is used (which authenticates itself), otherwise no more mail would arrive from other senders. Yes Microsoft, there you still have to do something.
That’s it so far, stay tuned and see you soon!
** midjourney string “Falsify the origin of an e-mail hacker, cinematic lighting –ar 1:2 –q 2“
