One of our consultants, Bob McKay, recently discovered what is a bizarre and absurd mistake by Microsoft in the Microsoft 365 Defender platform.
When configuring training phishing simulations in the Attack simulation training of Microsoft 365 Defender, he opted to use the built in training functionality so that users who were ‘successfully’ phished would be assigned a training course automatically.
When testing this functionality for the customer before rolling it out company-wide, he noticed that the ‘external email banner’ was being triggered because the email wasn’t being sent from an internal account. This is poses a problem because – ironically – users are likely to treat the training messages as more suspicious because of the banner.
Upon examining the sending email address – [email protected] – to see if it was safe to whitelist, he discovered that it was not in fact a Microsoft owned domain name but is owned by a family run home security firm called Omni Security Team based in Massachusetts!
Convinced that this must have been accidentally configured by the organisation, Bob went ahead and repeated the test on a fresh Microsoft 365 tenancy and lo-and behold, received training confirmation emails from Microsoft spoofing the same domain name.
Presumably this has come about because one of Microsoft’s developers ‘dropped in’ a temporary sender email address and never went back to change it before ‘go live’ (either that or they just assumed Microsoft owned that domain).
We’re not sure what is more concerning here, that it didn’t show up in testing or that so few people are using the service that it’s never been picked up on before!
We have raised this with Microsoft’s support teams but they responded with a confusing message stating “We are currently experiencing an issue with our tools. We can understand how critical this is to you.” and asking for a phone call (to discuss what, who knows?).
Why is this a problem?
Other than it being a bit of a farcical state of affairs, the fact that the sending address isn’t using a domain name owned by the organisation using the Microsoft 365 tools (or a Microsoft one) means that whitelisting it isn’t ideal.
On top of that, it also means that a whole bunch of sensitive information is being thrown at the mail servers of Omni Security Team and if they have a matching email address or a catchall setup, they are going to be receiving it.
Not only does the notification email use the securityteam.com domain name, there is also a handy calendar appointment attached to it where the organiser email address is also [email protected] and so when users accept or decline this appointment, the confirmation will be sent to [email protected].
In the short term until Microsoft addresses this issue, we recommend you do not use the phishing simulation tooling in Microsoft 365.
We have reached out to Omni Security Team for comment but haven’t received a response yet to see if they have been adversely affected.
Update (12 Jul 2022): Fix it already!
Unfortunately, unless you’ve got Satya Nadella’s mobile number, getting in touch with the right people at Microsoft is like shouting in to the abyss. First off, we raised a support case with Microsoft via the 365 platform on 7th July thinking that it would immediately get escalated – unfortunately, as of the 12th July the support engineer Gerald still seemed to be trying understand the problem. Gerald has repeatedly asked for a time for a phone call, despite us selecting email as my preferred communication channel (this is standard for Microsoft support – we suspect it allows the engineers to immediately put the support ticket in to a ‘waiting for customer response’ status).
Given that personally identifiable information (PII) data is easily accidentally sent to a third party because of this and so this could be considered a breach, we tried to report this via the Microsoft Security Response Center, unfortunately this just returned error-after-error of its own, preventing us from being able to use it (this comedy of errors would be hilarious if it were not so worrying).
Running out of ideas and because Satya isn’t accepting my calls, we decided to try posting on https://answers.microsoft.com/ as Microsoft employees and MVPs often frequent it.
Finally – a Microsoft employee appears to have read what our post and has escalated internally – watch this space, thanks “Creech”!!
Update (22 Jul 2022): Fixed – sort of!
While we’re still getting updates from Gerald asking for time slots for a phone call (no idea why), it appears the problem has been fixed – a test run last night confirmed that the emails being sent by the MIcrosoft 365 platform are now coming from attacksimulationtraining.com, a domain name that appears to be registered by Microsoft:
We say this is “sort-of” fixed because we still don’t understand why Microsoft would not let customers choose the sending email address, allowing them to use one of their own M365 hosted domain names – this would prevent the commonly used external email banners from appearing (e.g. “This email is from an external source, treat links with caution”).
It is hard enough getting employees to complete training assigned to them with sending them an email with a training link that has a warning at the top about clicking links in the email!! Yes it’s possible to exclude this domain from the rule that adds the warning banner but what if criminals start sending emails from that domain? (spoofing as Microsoft did accidentally).