Speedrun for a O365 Phishing infrastructure

Microsoft offers some Developer Tenants for O365. Those tenants can be used to set up a fishing infrastructure within minutes, emails will make it to almost all inboxes, specially in O365 environments.

And you get a nice Teams phishing infra as bonus

tl;dr

Exchange servers trust themselves (Cross-Tenant)
Developer tenants seem get the full reputation
Developer tenants can choose a similar subdomain name like the victim one
As an attacker controls the Entra-ID it is possible to spoof names
Microsoft’s Exchange does not check for missing SPF
It’s free if using the developer tenant

The following video shows the complete progress until a phishing mail can be send. The longest part is to wait until O365 is ready, which means there is a 5 min break. In total we are under 10 minutes.

Quick Walkthrough

Nothing of this is really new, however within the last year something in the exchange servers used for the dev tenants changed, which now allowes easy email phishing

Build it

Let’s jump into some details.

Register Dev Tenant

Microsoft offers the possibility to register a development AAD. https://developer.microsoft.com/en-us/microsoft-365/dev-program

Developer-AAD Sounds great, doesn’t it :)

We can go by the custom domain name to simply register something near to the tenant ID of the victim, like Corp-service.onmicorosft.com.

Last year, mails sent by those Dev Tenants got immediately flagged, but something changed.

I mean no standing still is a step backwards, isn’t it? :)

Done

Basically, we can just use this thing to send emails to other companies using regular O365 and the message will mostly make it to the inbox, if there are no further indicators of spam in the message. During my tests, also the available SPF, DKIM, DMARC rules did not protect against this.

But let’s at least improve some things.

Improve it

We can adjust some things to make our developer tenant phishier.

Name spoofing

As we control the Entra-ID, we control also the names of the user, meaning we can simply add stuff like Unicode, domain names, or just white spaces to the displayname.

Adding some special displayname

Allowing almost full Unicode, yes, including RtLO…(but this breaks a lot of things in the layouts) and “@” chars seems as a feature with room for improvement to me.

Custom domain

If wanted we could use a custom domain for the phishing. It is quite easy to setup and would make it a little bit rounder. However, we then mostly need some cooldown after registering the domain around 10 days or more.

Adding a custom domain if wanted

SPF, DKIM, DMARC

We can also do all the things for email security, I mean, we don’t want to get spoofed ourselves.

Use it

Here is where the real magic happens:

Let the magic happen

Just kidding

We can simply connect Outlook to the account and sent emails. Using other tools was really annoying, as the SMTP authentication is disabled by default and reactivating requires several steps. And if you make it finally, the IP adress of the sender is considered for the SPAM score and yeah most VPS do not have a great score :)

One other thing stood out during some testing is that Microsoft really does not like http:// links. The bad guys can not use https:// nor?

Warning If you use Outlook to send some previous crafted HTML messages, e.g., to remove some external sender banner, be aware, that Outlook will completely throw away your CSS and make all the things inline for the elements. This might remove your adjustments. To get around this, you can use VBA or extensions. In the video I use this VBA extension:
https://www.howto-outlook.com/howto/edit-html-source-code-email.htm#macrocode

Sidenotes

There is an interesting point about the SPF record. If you use a custom domain and did not set an SPF record, it still seems not to really matter. The detection rules check for a hardfail of the SPF, but as there is none, it also does not fail. And of course, as we also control the domain we can still set the SPF.

It is a little bit odd, that MS accepts mails from domains without any SPF record as the default setting. And it is really difficult to change this behaviour. Gave up after a while.

Teams

The developer tenant can also use Teams and if the corporation allows external communications this might be another great phishing channel.

Yes, we could write to Mr. Nadella with our fresh tenant

Filehosting

OneDrive and SharePoint are great resources for filesharing and can also be used here to host some payloads.

Conclusion

I have no clue, why somebody thought it would be a good idea to trust developer tenants like this. The name spoofing is also quite surprising, at least the “@” should imho not be possible to use for display names.

A question which may come in mind is: Q: “What does this differ to some email providers like Gmail?”
A: The attacker controls more things like the displayname and the subdomain. Furthermore, the developer tenant can also use Teams and can also be used to host files.

Countermeasures and indicators

Contact Microsoft and ask them, why it is not possible to check for the existence of a SPF record in an easy manner
Block @onmicrosoft.com messages, despite your own tenant. This might have some unwanted effects.

Outro

I thought quite some time if I should really publish a guide like this. As the steps are so easy, my conclusion was that it is better to try to raise awareness around this then the risk of abuse.

I also reported the “issue”, which in my opinion is not a vulnerability to Microsoft but got no response so far.

I could not decide on a meme here, so here a bunch of them :)