Securing access to Microsoft 365

Many organisations are making the move to cloud services. They provide some great benefits for an organisation's accessibility, productivity, and costs. But, cloud service models also mean a big change to how the network and systems are accessed.

Previously, remote access to the internal network required a VPN client, and access was limited to a small number of staff. Now all it takes is a web browser, and it’s accessible to anyone. It means that access to the network is available from multiple points over the internet. This changes the security landscape for an organisation.

As such, it's important to:

restrict the number of ways a user can authenticate, and
make sure you protect those ways with multi-factor authentication (MFA).

This guide provides some examples of attacks that CERT NZ has seen, and advice on how to secure access to M365. If you are experiencing an incident, read our advice on mitigating M365 attacks, and report it to CERT NZ.

Mitigating an M365 incident

Some of the controls mentioned below only apply to some licence levels, so check which are applicable to you.

Initial enrolment of MFA

When implementing MFA in your organisation, the number of accounts that haven’t yet MFA enabled will lessen over time. Accounts that haven't enabled MFA will still be at risk of phishing or unauthorised access.

For example, a victim account could be re-using a password disclosed in a breach. An attacker could use that password in an attempt against their M365 account.

Incidents we’ve seen

CERT NZ has seen incidents where attackers got credentials for an M365 account in an organisation that was rolling out MFA. The attacker logged in with stolen credentials for an account that hadn’t yet enrolled, and was prompted to configure MFA. The attacker configured MFA on their device, and continued their attack.

What you can do

To prevent this, your organisation can:

ensure users can only enrol in MFA from a trusted office network. This means your staff will have to enrol while they're in the office.
stop users accessing their accounts outside a trusted office network until they've configured MFA. This means that all logins outside the office will need to use MFA.

Microsoft’s MFA licencing External Link

Critical control: implementing multi-factor authentication

Legacy authentication protocols

Legacy authentication protocols are older protocols that don’t support multi-factor authentication. These protocols can only use credentials to open a connection, like a:

username
password, and
pre-configured, app-specific token.

Some Microsoft cloud apps, like Exchange Online, support these legacy authentication protocols. These protocols may not be blocked by default, or may be enabled to allow other legacy systems to operate.

Incidents we’ve seen

The most common legacy authentication protocols that CERT NZ sees being misused are mail protocols (IMAP/SMTP/POP).

User credentials are often harvested through a phishing page or from a data breach. They are then used to authenticate to O365 using SMTP. In this type of incident, even if the organisation had MFA configured, the attacker could just bypass it.

When user credentials are compromised, an attacker will often use Exchange Online PowerShell to modify configuration of an Exchange Online mailbox in order to gain persistence or make changes that don’t require interactive login. An example of this is to create a mailbox forwarding rule or an inbox rule to mask signs of data exfiltration. In normal circumstances a standard user shouldn’t need PowerShell functionality.

What you can do

To disable legacy authentication protocols, your organisation can:

block traffic using legacy authentication protocols in Active Directory Federation Service (if you use it).
block traffic using legacy authentication protocols in Azure Active Directory. You can do this by configuring conditional access policies.

How to: Block legacy authentication to Azure AD with conditional access – Microsoft External Link

Your organisation may still need these legacy authentication protocols. If so, you can configure conditional access policies on any Microsoft cloud apps that support legacy authentication protocols. This includes SharePoint Online and Exchange Online.

Create a conditional access policy for Exchange on-premises – Microsoft External Link

Manage SharePoint Online access in System Centre Configuration Manager - Microsoft External Link

To further reduce your organisation’s attack surface, you should disable the ability for standard Microsoft 365 users to use remote Exchange Online PowerShell.

Disable access to Exchange Online PowerShell External Link

Disabling unnecessary services and protocols

Conditional access

Conditional access is a feature in Microsoft products. It allows you to control access based on a set of conditions. You can use it to control what access you allow to cloud applications, and how you enforce MFA. There are multiple conditions that you can use to configure a conditional access policy. It can be complex to implement correctly.

Incidents we’ve seen

CERT NZ has received reports of incidents where the configuration of the conditional access policy let users bypass MFA. This meant that attackers were able to manipulate their login behaviour to trigger a conditional access policy where the rule outcome was 'no MFA'. They were not prompted for a one-time code or asked to respond to a push notification.

What you can do

If you're using conditional access to manage MFA, your organisation should test your conditional access policy with positive and negative tests. For example, if you have a policy rule that results in a user not having to use MFA, make sure you have multiple use cases where the expected outcome is 'prompted for MFA' and 'no MFA needed'.

If there are any tests that don’t have the outcome you expected, re-evaluate the policy before using it. Allowing a user to skip MFA can introduce a large risk. Due to the high number of incidents CERT NZ sees involving O365, the recommendation is that you use MFA for all access attempts. If it is skipped, test all use cases before making it available to your users.

Implementing MFA