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
- 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.
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
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
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? :)
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.
We can adjust some things to make our developer tenant phishier.
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.
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.
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.
SPF, DKIM, DMARC
We can also do all the things for email security, I mean, we don’t want to get spoofed ourselves.
Here is where the real magic happens:
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
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:
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.
The developer tenant can also use Teams and if the corporation allows external communications this might be another great phishing channel.
OneDrive and SharePoint are great resources for filesharing and can also be used here to host some payloads.
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.
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 :)