Microsoft 365 Breaches - As preventable as they are common

The Problem

It seems like every other day there is a public announcement of a compromise involving unauthorised access to Microsoft 365. Privately, we are called in more often than we would like to deconstruct a compromise and determine if a notifiable data breach has occurred.

As organisations move to adopt more and more features, tools and products of M365, more data is finding its way into the platform, becoming the defacto centralised repository for all types of commercial, sensitive, personal and confidential information.

Due to the frequency and commonality of these Microsoft 365 breaches, I wanted to deconstruct the crucial elements and provide recommendations for how to prevent these based on our first-hand experiences.

Entry Points

The manner in which the breach occurred can be summarised as one (or more) of the following:

1. Inadequate or inappropriate M365 security configuration
2. Weak or ineffective implementation of (often complicated) security controls
3. Human behaviour

I'll cover each of these individually.

#1 - Inadequate or inappropriate M365 security configuration

Microsoft provides a new tenancy with many, many default settings and many of the security configuration parameters are designed for maximum compatibility. Think the 5 year old multifunction printer that does not support TLS for SMTP, so to avoid interrupting the scan function, weaker email protocols are supported for all mailboxes by default.

Microsoft has been making some great improvements over time by adjusting defaults and in some cases, retrospectively changing weak protocol support, however it is limited by the risk of causing disruptions.

There are over 150 basic configuration paramaters that need to be set and the vast majority are only accessible via powershell or by using the Graph API. This leaves many parameters in a weak or exposed state, where they could be used individually to gain unauthorised access or chained together to exploit a human to gain access.

Example: Bypassing MFA

The classic example is where 'legacy' authentication is enabled to support older email clients such as Outlook 2010. Larger organisations may have invested heavily in perpetual Office licenses and may be slow to replace these with M365 subscriptions that include the newer client. Organisations may opt for the frontline worker 'F' license type rather than the enterprise 'E' license for cost reasons where frontline workers don't require the same functionality as back office corporate staff.

Modern (read secure) authentication is used by current versions of Outlook, however when Outlook 2010 tries to connect to M365 with legacy authentication enabled, M365 will downgrade its security for the connection to support Outlook 2010. Since legacy authentication does not support multifactor authentication, attackers have been using this technique to bypass MFA. Attackers harvest, guess weak or reuse previously breached usernames and passwords to connect to M356 using what looks like Outlook 2010 to trigger a legacy authentication protocol downgrade, thereby bypassing MFA.

#2 - Weak or ineffective implementation of (often complicated) security controls

Time and time again we're validating the effectiveness of security controls only to discover what appears like valid in-place security controls are anything but. Whilst the M365 GUI can show MFA enabled or enforced for particular users, legacy authentication (#1 above) is not the only weakness. Azure - the underlying authentication and authorisation of M365 - includes Conditional Access Policies (CAPs) as one powerful feature included in some license variants.

Example: The Ineffective Access Policy

CAPs are used to provide granular access to applications with layered grant, deny or challenge rulesets. The issue is one of complexity and we are often presented with 20+ CAPs that individually seem to provide logical access policies, however when digging deeper and validating common scenarios we discover glaring gaps and unexpected behaviour resulting in layered scope inclusions and exclusions. We've discovered entire business units that never require MFA or could maintain persistent sessions originating from high-risk countries for months.

What the GUI seems to suggest is a reasonable control and expected behaviour, however this presents a false sense of security. I suspect that the simplicity of the CAP interface - literally clicking a few checkboxes - attracts those without experience and expertise into configuring these settings and reporting to management as being in place and effective. Unfortunately, we are yet to come across a single M365 environment secured by a general IT MSP (versus a cyber security specialist) that does not have a difference in expected vs actual security control implementation.

#3 - Human Behaviour

Much has been written about human behaviour and how it affects cyber security, however it often boils down to everyone is busy. With this comes behaviours and often shortcuts in order to be more efficient during their busy work days (or nights). Human risk with regards to M365 compromises can be broken down into the following:

• (i) Password reuse
• (ii) Password capture
• (iii) MFA fatigue

The first two are fairly common and coupled with the MFA bypass covered in #1 above, are trivial to exploit and gain unauthorised access.

Example: Ineffective MFA

MFA is a no brainer and one of the best bang-for-buck security controls that you can implement. However, its implementation and effect on humans means its protection can deteriorate. MFA fatigue and phishing-resistant MFA are two examples of how MFA is implemented is just as important as implementing it.

Firstly is the scenario that led to the Twitter breach - too many MFA prompts leading to someone clicking to grant access to an unauthorised access attempt that triggered an MFA prompt. When you receive hundreds of MFA approval requests per day, how do you know which ones are legitimate?

Rather than a push notification request to grant or deny, the request asks to enter the number displayed at the point of making the request. I.e. if you have not made the request, you won't know the number associated with the request to enter into your mobile authenticator application. This technique (along with physical tokens) are resistant to phishing and the effects of MFA fatigue.

Impact

As more and more data is traversing or being stored in M365, the impact of an M365 breach increases. We have seen environments where over 10 years of sensitive customer PII is stored in user or shared mailboxes, with a treasure trove of identification documents in some cases. In this case, Notifiable Data Breaches scheme required the organisation to manually sift through thousands of individual emails and advise individuals who may have been impacted by the breach.

To further complicate assessing the impact of a breach, certain M365 licenses include an ability, if enabled and properly configured, to access item-level auditing. What this allows us to do when performing a forensic investigation is determine which individual data objects were accessed, such as individual emails. It's far better to know exactly what was accessed and respond accordingly, rather than having to assume all content in the mailbox was compromised. However, the function needs to be enabled!

Further compounding the issue are processes and sharing policies. Sending attachments vs OneDrive/SharePoint links, non-expiring or anonymous (sharable) links are all configurable and policies enforced to help users avoid widening the impact of an account compromise.

The other consideration is duration of stored activity. The default is to store logs for 90 days and this is also a limitation for most M365 license tiers. This proves a challenge when trying to determine when the original breach occurred, what has been accessed and if other accounts are affected.

At the end of the day, what we're aiming for - and it's very much achievable - is make it difficult to compromise M365, but when an account is compromised, the impact is inconvenience rather than catastrophe.

Recommendations

• Appropriately and security configure the 150+ tenant-wide and mailbox-specific configuration parameters, including disabling insecure protocols, options and practices (get out your PowerShell)
• Implement security controls effectively and comprehensively test control effectiveness - not just what the GUI infers
• Implement phishing-resistant MFA
• Train staff using an omni-channel approach to information security awareness to achieve cut-through (this means more than template-based phishing and computer-based training)
• Monitor for credential reuse and compromise
• Formulate a holistic information processing and storage approach which includes organisation-wide policies, staff training and corresponding security controls to support secure information sharing
• Don't use email as file transfer!
• Implement monitoring of Azure and M365 activity to detect and reliably contain account breaches within minutes
• Centrally store security event data for longer than 90 days - ideally 12 months online, indexed and readily queried

Feel free to reach out to me to discuss how you can reliably secure M365 against common breach techniques.