It might sound strange to hear that Microsoft, a company who goes to great lengths to protect computers and networks, is one of the biggest contributors to phishing and fraud on the planet. It's true unfortunately.
They aren't actually committing the acts themselves of course, but they are enabling the problem by withdrawing support for standards designed to help stop it. Here's why this is such a big deal.
UPDATE 4/12/2023: After years, Microsoft is finally fixing this by honoring p=reject. This is a huge improvement and deserves to be applauded. The work isn't done though. We need aggregate reports to avoid blind spots during our implementation. Offering the reports for enterprises is a great step though.
// Share.on([hacker news,
linkedin,
twitter,
facebook,
reddit])
@Microsoft is finally taking steps to fix their DMARC problem! I'm going to take partial credit since it happened so close after this blog post. You're welcome internet. #dmarc #phishing #fraudhttps://t.co/GgFrYMbPUP
— Barry Jones (@brightball) April 12, 2023
Phishing is the act of tricking a person into giving away sensitive information. This can happen in a number of different ways and formats, but email has been the most common for a very long time simply because it's naturally vulnerable. Email is insecure by default.
Yes, really. If I decided I wanted to open a pirate themed gym call Slimmer Ye Timbers, one of the first steps would be to buy the domain name slimmeryetimbers.com. If I wanted to setup a website for it, I would have to configure the domain name to point to wherever the website was hosted. If I wanted to receive email to @slimmeryetimbers.com addresses, I would also have to configure the domain name to point to wherever it should receive email.
But if I wanted to send email from @slimmeryetimbers.com addresses...I don't have to do anything at all. Any server, anywhere can send email claiming it's from my @slimmeryetimbers.com address and that's by far the biggest enabler to email phishing that exists. So how do we stop it?
Over the years a number of competing email standards have appeared to try to fix the email problem until over a decade ago when the DMARC standard emerged. DMARC enables you, the domain owner, to identify what emails actually came from your domain and tell a receiving email server to throw away the message if it doesn't pass the test. It lets you turn off email from every email source that you didn't authorize.
I'm not going to get into exactly how to set up DMARC in this post, but if you are interested in a more complete explanation I recently put together a detailed 3 part series on the topic.
As it relates to Microsoft, you simply need to understand that DMARC has two main considerations: initial setup and then enforcement. Microsoft broke both of these and it's endangering anyone using their email services.
It's also important to understand that the issues I'm about to describe come from intentional actions on the part of Microsoft itself. At one point, they fully adhered to the specification. Then later, they changed. Years later they have not restored adherence to the specification.
ANNOUNCEMENT: At BSides on October 28th, 2023 I announced the upcoming 2024 private beta of dmarcSTAR, a service that approaches DMARC in what I believe is the ideal manner after over a decade of experience with the specification. Read more at dmarcSTAR.com.
Before you can turn DMARC on, you have to make sure that everything is setup correctly, otherwise you risk having legitimate messages dropped. This is covered in the specification with the DMARC Aggregate Report, which allows you to receive a daily emailed report that summarizes all of the messages an email provider received claiming to be from your domain.
For example, Yahoo and Google will each send me a report about how many messages they received from @slimmeryetimbers.com. The reports will contain the total number of messages from each IP address and some details about whether they passed the DMARC check or not. These reports are critical for a couple of reasons.
First, they help you to identify the scope of the project. If you have a new domain, you might only have a single web server sending email on your behalf which makes life pretty easy. If your company has been around for many years, you could have dozens, hundreds or thousands of servers sending email on behalf of your domain. Many of them may be fraudulent.
Second, as you configure your sending sources to pass SPF and DKIM alignment checks (the building blocks of DMARC), the reports will let you know if those sources are passing successfully. Sources could include anything from your main company email, a newsletter service, website or application emails, a 3rd party email provider like Sendgrid to independent servers on your network.
If you turn on DMARC enforcement and one of these isn't setup correctly, the messages from them will cease to be delivered successfully. At a large company with many different departments, any one of these that suddenly stops delivering will likely result in a lot of internal politics that could go as far as seeing the DMARC project cancelled entirely.
Microsoft stopped sending the reports.
That means any servers that are only sending email to Office 365 email accounts won't have any visibility on the reports at all. If your company is using Office 365 for email and you have internal systems sending automated messages, reports, prospect summaries, sales numbers, etc...every one of them will be missing from those DMARC reports because Microsoft made the decision to stop sending them.
That means, if you turn on DMARC enforcement and suddenly an expected message stops showing up somebody is going to get angry. Is the blame going to be aimed at Microsoft for not sending the reports that would have prevented this problem? No. The blame will go to the DMARC project itself and the organization will likely drop it.
If you'd like to verify this, dmarcian publishes a daily list of DMARC reporters that you can feel free to review at any time. Yahoo, IronPort, Google, Optum, Amazon, Comcast, Rackspace (emailsrvr) and almost 5,000 others send these reports yet one of the biggest email providers in the world just decided, "Nah."
The Microsoft documentation is more timid about this, stating only that "Mails may not be sent out daily." Based on the dmarcian reports linked above, they don't appear to be sent at all.
They've even gone as far as to suggest visiting their own vendor catalog to find 3rd parties who may offer reporting, via a "Tip" on that same documentation section. Instead of providing the free report, it appears that they want to up sell them instead...but even those vendors don't appear to provide these reports on Microsoft's behalf.
Microsoft isn't the only one either, just the most egregious because of how many people are made vulnerable due to their decision.
If it wasn't enough to know that setting up DMARC is significantly harder if your company made the mistake of choosing Office 365, then you're going to be happy to know that they even broken DMARC for companies who did get it setup successfully.
At it's core, a DMARC record is a simple DNS entry. There are a few options that can be configured, but the important option is the Policy, indicated by p= that can be set to none, quarantine or reject. Projects begin with none then move to quarantine before completing the process at reject. Each of these indicates a phase of the process of deploying DMARC and the stringency of the rules.
none offers no enforcement, but allows you to collect aggregate reports (which Microsoft no longer sends) so you can ensure things are setup correctly.quarantine is where you move when you think you're ready to turn things on, but you want to be cautious. This will cause messages that fail DMARC checks to be sent to the spam folder so that if you suddenly start getting support requests about missing emails, you can direct people to look for the messages in their spam folder. If you don't get any of those complaints, everything is likely working fine but many people opt to remain in quarantine for a couple of months as a precaution.reject is the final step, when everything is working successfully and tells email receivers to drop failing messages entirely if they aren't passing DMARC, so they never even make it to the spam folder.Microsoft decided to ignore reject policies and simply send everything to the spam folder as if your DMARC report was in a permanent state of quarantine. You can see it right here in their documentation.
If the DMARC policy of the sending server is
p=reject, Exchange Online Protection (EOP) marks the message as spoof instead of rejecting it. In other words, for inbound email, Microsoft 365 treatsp=rejectandp=quarantinethe same way. Admins can define the action to take on messages classified as spoof within the anti-phishing policy.
The anti-phishing policy should be standards compliant by default. If you're going to provide an option to change it, the admin should be making an intentional decision to reduce the security profile of their organization that's filled with warnings about the danger. Defaults like this ensures that almost everyone will remain opted out until somebody realizes there is a problem. Danger by default is a terrible decision.
Many people don't understand why this is a big deal, after all it's still in the spam folder right?
Unfortunately, no. There are a lot of side effects. As long as a message is in the spam folder, a user can decide to flag it as "not spam". They can create an email rule based on the From address that may or may not take the spam folder into account.
That also means that I can still send a message claiming to be from your domain and then call you, pretending to be the person the message was from. "Bob, did you get my message about our call that started 5 minutes ago? No? Check your spam folder it's probably in there. Great, you found it. Just click that link and join the call..." That's one of many ways that social engineering works. If you're using Office 365, now everybody in your company is vulnerable to that attack vector simply because Microsoft chose to make up their own rules.
It doesn't matter if your company or my company setup DMARC with a complete reject policy, because Microsoft will ignore it and ensure that the message at least made it to your spam folder. My domain can have a perfect email policy including DMARC reject, but if you are using Exchange then my domain can still be imitated. Paypal can be imitated. A vendor invoicing system can be imitated to trick your staff into paying an invoice that did not come from the real vendor.
All because Microsoft decided to change the rules of a standard that exists to prevent these exact problems...even though they still advocate for you to use DMARC!
It doesn't stop there though. Everybody at your company doesn't know about how email works. Shocking, I know.
Somebody from the company signs up for a service that will send some emails on behalf of the company, they may think that it's working if they see things delivered to the spam folder. They may even start providing advice like, "Add us to your contact list" or the like. The larger the company, the more of these there will be.
If the message isn't delivered at all, the request must go to IT to help get it setup. They can't go around proper channels. You bypass the Shadow IT problem at your company entirely and the new service can easily be configured appropriately for your company standards.
Even if it doesn't go through proper channels, you'll still see the new service appear in your DMARC reports...but since Microsoft doesn't send those you won't be able to identify the problem there either. That will make keeping your DMARC policy up to date as the organization changes over time more and more difficult as time goes on.
As long as Microsoft continues non-adherence to the DMARC specification, Office 365 email (Outlook, Exchange) should be considered an active security vulnerability which exposes all of their customers to ongoing threats of phishing, fraud, business email compromise (BEC) aka spear phishing and more. If you're a customer of a service using Office 365, you should consider that service vulnerable to potential breach simply because all of their staff are made easier targets.
"As long as @Microsoft continues non-adherence to the #DMARC specification, using @Office365 email (Outlook/Exchange) should be considered a #security vulnerability..." https://t.co/GgFrYMbPUP #security #emailsecurity #microsoft #phishing #dmarc
— Barry Jones (@brightball) February 23, 2023
How can you fix it? Start calling people out on it during sales calls. There's no faster driver of change than sales people who lost a deal because a box wasn't checked. Include the question on security questionnaires. Look up the email provider for the company when you receive a sales call and reply with, "I'm sorry, but we cannot use a service with a vulnerable email provider like Office 365. I'd be happy to hear more if your company switches to a provider that supports DMARC."
Microsoft already terrorized the entire world for over a decade with Internet Explorer vulnerabilities. Those holes could at least be classified as software bugs.
According to the FBI, BEC attacks have cost businesses $43 billion since 2016. It would be an interesting study to see how many of those dollars were associated with businesses who either lacked DMARC entirely or were using a provider who didn't properly support it and were compromised by a message that should never have been delivered.
The choice to intentionally compromise the DMARC specification is willful negligence and should be treated as such.
// Share.on([hacker news,
linkedin,
twitter,
facebook,
reddit])