Microsoft recently sent data breach notifications to Microsoft 365 customers that were flagged as spam and even blocked by the company’s own security tools, according to security researchers.
The emails were flagged – and raised concerns among Microsoft customers – for a few reasons: they asked for high-level account information, included a link that was not clearly connected to Microsoft, and also appeared to improperly implement DMARC anti-spoofing protocols.
While Microsoft deserves credit for transparency, the world’s largest software company also demonstrated the perils of failing to follow some pretty essential email authentication and security practices.
Microsoft Emails Lacked SPF and DKIM Authentication
The issue was flagged by security researcher Kevin Beaumont, whose LinkedIn post on the issue was shared more than 400 times.
“Check your email logs (including Exchange Online) for an email from [email protected],” Beaumont wrote. “Microsoft had a breach by Russia impacting customer data and didn’t follow the Microsoft 365 customer data breach process.
“The notifications aren’t in the portal, they emailed tenant admins instead. The emails can go into spam – and tenant admin accounts are supposed to be secure breakglass accounts without email. They also haven’t informed orgs via account managers. You want to check all emails going back to June. It is widespread.”
A commenter, Thanos Vrachnos, replied that “Several of my clients received this email. All of them were worried it was phishing, since no SPF & DKIM were used according to the email headers and the URL mentioned in the email message was hosted as a simple (almost dummy) Azure PowerApp with a simple DV SSL certificate issued by another trusted CA and without any organization info (all other MS domains have OV/EV certificates issued by Microsoft as a publicly trusted CA)…weird way for a provider like this to communicate an important issue to potentially affected customers.”
The notification – from a Midnight Blizzard attack earlier this year – was also flagged by Microsoft customers on company forums too. On Mastodon, Beaumont noted more than 500 organizations where the emails had been flagged as phishing attempts and submitted to sandboxes.
Getting DMARC Right
Microsoft’s own 365 documentation includes a primer on “How SPF, DKIM, and DMARC work together to authenticate email message senders.” In Microsoft’s own words:
- The Sender Policy Framework (SPF) specifies the source email servers that are authorized to send mail for the domain.
- DomainKeys Identified Mail (DKIM) uses a domain to digitally sign important elements of the message to ensure the message hasn’t been altered in transit.
- Domain-based Message Authentication, Reporting and Conformance (DMARC) specifies the action for messages that fail SPF or DKIM checks for senders in the domain, and specifies where to send the DMARC results (reporting).
The challenge with DMARC, SPF and DKIM is they must be implemented properly to provide adequate protection.
Just last week, email security vendor EasyDMARC released a study that found that while 61% of top manufacturing companies have implemented DMARC, only 19% have adopted the stringent p=reject policy that provides full protection against phishing and spoofing.
DMARC takes time to get right. You implement and verify SPF, DKIM and DMARC policies; deploy DMARC in monitoring mode (p=none); monitor reports to identify legitimate email sources that are getting rejected; and then over time, as issues get resolved, increase enforcement to ‘p=quarantine’ or ‘p=reject.’
DMARC offers great promise for fighting spoofing and phishing, the point where so many cyber attacks start. Taking time to get it right could greatly improve your cybersecurity defenses – and keep your organization from embarrassing public scrutiny.