Office 365, MFA + Myths

In this blog, we’re taking a look at the ubiquitousness of Office 365, and how that popularity poses a special challenge for MFA-based security. But we also detail ways to remove false assumptions and combate the specific threats. Our key solutions toward bridging the gaps in MFA enforcement are described in greater detail within our white paper, Securing Office 365 with Okta.

As organizations continue to move towards cloud infrastructure and applications, there is growing adoption of cloud-based email services. It’s no surprise that Office 365 is the prefered choice for many businesses, and has become the de facto standard of the business productivity suite. Our Business @ Work statistics show that Office 365 is the most popular application among our customers. But, as the most widely-used cloud service, Office 365 has the burden of being constantly under attack. The Microsoft security intelligence report, volume 22 indicates an almost 3-fold increase in attacks against Office 365 accounts in a single year.

Attacks like password spray, brute force, KnockKnock, and phishing have been targeting Office 365 cloud users for years. The common denominator of all these attacks is access to the right combination of username and password. These attacks have a higher probability of success if the email accounts are only protected by single factor authentication such as a password. Although not a silver bullet, having multi-factor authentication (MFA) for accessing Office 365 (or email in general) is imperative. MFA, using strong factors, discourages aforementioned attacks by introducing an extra, required authentication element to complete the sign-in process.

The myth of total protection!

If MFA is the efficient protection against aforementioned attacks, and Office 365 has the ability to enforce it, why is there an increase in the number of successful attacks on Office 365? Well, it’s possible that organizations are investing in MFA, but not effectively implementing the control. Comprehensively enforcing MFA with Office 365 is a challenge. While Microsoft Exchange does provide a mechanism for enforcing MFA using modern authentication, it is not supported on every sign-in method supported by Office 365. Only email clients built with ADAL support use the modern authentication flow, while legacy clients rely on only basic authentication. Let’s look at some possible scenarios that could potentially break MFA enforcement on Office 365:

• Among the access protocols supported by the Office 365 suite, legacy protocols like POP and IMAP can only support basic authentication. So, if an email client is relying on these protocols to access Office 365, it will only require username and password for login and cannot enforce MFA.
• Access protocols that support modern authentication, like Exchange ActiveSync, Exchange Web Service (EWS), MAPI and PowerShell, can be defaulted to use basic authentication. For example, the latest native mail client on Windows 10 OS uses modern authentication over MAPI to authenticate and access Office 365. However, by making registry changes it can be configured, by the end user, to use MAPI over basic authentication.
• Not all email clients are built with ADAL/modern authentication support. Even if an email client supports protocols like Exchange ActiveSync, EWS or MAPI, it may not support modern authentication. For instance, the latest Outlook client on Mac OS uses EWS over modern authentication but the native Mac OS mail client uses EWS over basic authentication—the same access protocol but different authentication flows.
• Lastly, Office 365 currently does not offer the capability to disable basic authentication in Exchange. Hence, there is no server-side control that can be used to enforce only modern authentication flow on clients.

This demonstrates that even after having modern authentication enabled and MFA policies enforced, there is still a significant number of authentication flows that are only secured by basic authentication. Given the significant implications of not enforcing MFA, it’s still not getting the attention it merits. And unfortunately, most IT admins only learn about gaps after an adverse event, such as an email compromise, takes place.

How serious is this?

According to a July 12th, 2018 FBI report, from Oct 2013 to May 2018, organizations incurred over $12 billion in losses due to Business Email Compromise (BEC) attacks. BECs are efficient adversaries, often used as the launchpad to further compromise both internal and external users.

Also, if attackers are able to compromise Office 365 admin credentials, they also have the ability to scan the email content of an entire organization. Attacks can include infiltrating sensitive data and creating email forwarding rules; a catastrophic for any organization.

Data loss attacks are not the only impact to organizations. They can also incur significant economic, brand, and compliance losses. In fact, Beazley’s breach insight report shows a total financial cost of $2 million to conduct a BEC compromise investigation.

A rise in attack popularity

Another angle to consider in understanding the seriousness of MFA enforcement is its popularity among attackers. The latest industry threat reports show how aware adversaries are of the gaps in MFA enforcement on Office 365, and how they increasingly target corporate email. Recently, a nation-state actor was indicted by the US Department of Justice for a massive cybertheft campaign against universities, the private sector, government agencies, and other sectors, using the aforementioned attack vectors. This particular actor used a combination of phishing and password spraying attacks to gain control of email accounts and harvest intellectual property.

Okta Blue Team observations

The Okta Blue Team actively responds to countless password spray and bruteforce attempts against our customers. Of all the password spray attempts made against the various SaaS applications used by Okta customers, more than 60% were aimed at Office 365 alone. Attackers break into email accounts by running automated campaigns, leveraging targets ranging from personal devices to wide-scale infrastructure. But typically, attacks against Office 365 are carried out through a compromised infrastructure.

We’ve observed that, more often than not, attackers use servers that host vulnerable or less secure software such as MikroTik, RealVNC, or Dropbear.

Password spraying and brute force attacks can be highly sophisticated because they consciously blend in with legitimate access. Such attacks can be challenging for an untrained admin to detect. In fact, the most advanced and well-funded actors can successfully avoid account lockouts and detection by conducting “low and slow” attacks against network traffic, and monitoring the number of login attempts against any one account.

Considering these risks and challenges in enforcing MFA on Office 365, it is critical that IT admins and security teams ensure full MFA enforcement by investing in assessment and testing of their Office 365 implementations.

How can organizations secure Office 365?

Enforcing MFA onto an entire Office 365 mail client spectrum is mostly an exercise in mail client policies. It’s execution depends on the Identity Provider (IdP), while admin action depends on the environment, and whether the IdP is Okta, Azure AD or some other IdP alternative.

At the core of enforcing MFA on Office 365, we need to disable the use of basic authentication. We don’t have server-side controls on Exchange to disable basic authentication, so setting client access policies is the only effective approach to ensure that only MFA-enforced access is allowed through. These client access policies govern access to Office 365 based on attributes like client types, network location, user group membership and password-only vs. password and MFA. However, applying these client access policies comes with trade-offs. Email clients that are not built with Azure Active Directory Authentication Libraries (ADAL) support cannot use modern authentication, and hence, will be prevented from accessing Office 365.

Client access policies for Okta customers

Okta created the Office 365 client access policy feature to provide granular access control on clients accessing Office 365. In addition, the Securing Office 365 with Okta whitepaper contains detailed steps on how to configure these client access policies in Okta, the configuration changes required on Office 365, and the list of email clients that support modern authentication.

Client access policies for non-Okta customers

For organizations using Azure Active Directory for authentication and MFA, you’ll want to ensure that conditional access policies are configured to govern Office 365 access. Okta has not tested this approach, so your system may require additional research and testing.

If you are using a 3rd-party IdP for MFA authentication, we recommend working with them to evaluate potential gaps in MFA enforcement on Office 365 to ensure that your Office 365 deployment is in its most secure state.

For more details on how to configure Client Access Policies to bridge the gaps in MFA enforcement, check out our Securing Office 365 with Okta whitepaper!