Protect Your Office 365 Accounts from Takeover

Workforces are becoming more distributed due to the pandemic or the desire to hire the best talent wherever in the world it may be. In turn, many are moving their operations into the cloud, starting with email, being one of the most common applications. Many companies that use Microsoft Exchange on-premises are naturally choosing Microsoft Office 365 (O365) in the cloud. However, security in the cloud is different from on-premises. The administrative interfaces for cloud applications are quite different than their on-premises counterparts, and they have different configuration options. If you are planning on using O365, these are the things you need to do to secure your O365 accounts.

The top three threats to O365 accounts are password-based attacks, credential phishing, and consent phishing (for more details see our Threat Insight report). The following configuration recommendations are based on Microsoft best practices and assume only the entry-level edition of O365 and the edition of Azure Active Directory (AAD) included with O365. Premium editions of AAD provide more advanced options, but we will only refer to them without going into details. Even the basic options, however, provide good protection against these threats.

Password-based attacks

The three most common password-based attacks for O365 are credential stuffing, brute-force, and password spray.

1. Credential stuffing. Credential stuffing attacks use compromised credentials exposed to the public after a breach against organizations and hope that victims reused their credentials on multiple sites.
   
   
2. Brute-force. Brute force attacks submit many username/password combinations for authentication on the odd chance that they get one correct. The odds of a brute-force attack working are relatively low because of account lockout but this attack is cheap and sometimes attackers get lucky.
   
   
3. Password spray. Password spray attacks use a relatively small number of commonly used passwords one at a time across all known accounts. Password spray attacks are popular because they move slowly enough to avoid account lockouts.

The two most important things you can do to protect your O365 accounts from password-based attacks are: (1) turn on Multi-factor Authentication (MFA) and (2) turn off Legacy Authentication for all user accounts (use long complex passwords for service accounts). Both can be configured through “Properties > Enable Security defaults > Manage Security defaults” in the Azure Portal. The “Multi-factor Authentication” feature in “Security defaults” requires users to authenticate using the Microsoft Authenticator application after they enter their passwords. The Microsoft Authenticator application is the only additional means of authentication available via “Security defaults.”

Multi-factor authentication however cannot be used with Legacy Authentication. Older versions of Office clients or any other client that uses legacy mail protocols like IMAP, SMTP, or POP use Legacy Authentication. You can find out whether any of your applications are using Legacy Authentication by doing the following:

1. Navigate to the “Azure Portal > Azure Active Directory > Sign-ins.”
2. Add the Client App column if it is not shown by clicking on ”Columns > Client App.”
3. Filter by Client App. Check all the Legacy Authentication Clients options presented.
4. Filter by Status > Success.
5. Expand your date range if necessary using the date filter.
6. If you have activated the new sign-in activity reports preview, repeat the above steps also on the User sign-ins (non-interactive) tab.

These applications must be updated to versions that use “Modern Authentication” (e.g. Outlook 2013 or later) before turning off Legacy Authentication. Applying these two configuration changes will stop the vast majority of known attacks on O365 accounts. 

Here are some additional features that can protect your O365 accounts from password-based attacks.  Note that they do require Premium editions of Azure Active Directory.

Premium P1 Edition

• Conditional access allows authentication by text message or phone (requires Premium edition). 
  
  
• Azure banned password policy blocks passwords based on a global list of well-known weaknesses as well as a custom list (the global banned list applies to all cloud-only AAD users (O365 or free); hybrid on-premise/cloud environments or custom lists require Premium editions).
  
  
• AAD connect health with ADFS monitors on-premise identity infrastructure via AAD and will alert on bad password attempts and risky IP addresses (requires federation and Premium).

• AAD connect password hash sync synchronizes a hash of a password hash from the on premise AD server with AAD (requires a hybrid on-premise/cloud environment).

• Leaked credential reporting attempts to match publicly available username/passwords from the dark web or law enforcement agencies with username/passwords in AAD and when a match is found the account is marked as high risk. You should force a password reset for these accounts.

• If your on-premises AD server is compromised, you can turn it off and continue to use AAD for authentication and authorization (requires federation). 

Premium P2 Edition

• AAD privilege identity management (PIM) removes standing Admin access and requires all Admins (O365, AAD, Azure) to use MFA every time they perform an administrative action (requires Premium 2 edition, at least for the Admins). 

Turning on MFA and turning off Legacy Authentication are sufficient for most small-to-medium or mid-market businesses without special security requirements.  However these features can make protecting your O365 accounts more convenient and effective. The one exception to this rule is service accounts, as they cannot use MFA. AAD connect health may be especially useful for businesses that use service accounts.

Credential phishing

Phishing attempts often appear as a pop-up or an email indicating that account credentials are ‘suspended’, need to be ‘verified’ or ‘reset’. Unsuspecting users follow the prompts, landing on a well-crafted page where they are prompted to enter credentials. Attackers then have the login credentials and access to the account.

In addition to turning on MFA as mentioned above, the following features available in Premium editions of AAD help protect against credential phishing.

• Conditional access policies can block access by location or ip address (requires Premium P1). 
  
  
• AAD identity protection can be used in conjunction with conditional access to create risk based policies (requires Premium P2). The policies include:
  
  
• User risk policy. Identifies and responds to user accounts that may have compromised credentials. Can prompt the user to create a new password.
  
  
• Sign in risk policy. Identifies and responds to suspicious sign-in attempts. Can prompt the user to provide additional forms of verification using Azure AD Multi-Factor Authentication.
  
  
• MFA registration policy. Make sure users are registered for Azure AD Multi-Factor Authentication. If a sign-in risk policy prompts for MFA, the user must already be registered for Azure AD Multi-Factor Authentication.

In general, MFA should be enough protection for most companies.  However, MFA can be bypassed by particularly determined attackers. For those that need additional protection, the Premium editions of AAD may be worth the expense.

Consent phishing

Sometimes known as ‘App Attacks’, OAuth attacks occur when threat actors leverage an O365 app created using information stolen from a legitimate organization. The attacker sends an email, text, or other communication purporting to be from Microsoft asking users to complete an action. After the user signs into their O365 account, they’re redirected to the official O365 consent process that prompts them to grant permissions to the actor’s application. Once permission is granted, the attacker will have persistent access to the O365 account(s).

You can limit the ability of users to add applications, as well as limit the permissions that those applications have when added. Here are three of the four options: 

• Disable user consent. Users cannot grant permissions to applications. This option is the safest but may generate additional requests for admins to add new applications.
  
  
• Users can consent to apps from verified publishers or your organization, but only for permissions you select. Microsoft enables users to select from a list of applications from providers that have been verified via its Microsoft Partners Network. This option reduces risk and provides more flexibility than admin-only, but it does require admins to decide proactively which permissions are acceptable for all verified applications. A one-size fits all approach may not work in some cases.
  
  
• Users can consent to all apps. We do not recommend using this option.

The fourth option is custom app policies, but that's outside the scope of this blog post. 

Once you decide which option is right for your business, you can configure it by doing the following:

1. Sign in to the Azure portal as a Global Administrator.
2. Select “Azure Active Directory > Enterprise applications > Consent and permissions > User consent settings.”
3. Under “User consent for applications”, select which consent setting you'd like to configure for all users.
4. Select “Save” to save your settings.

The limits you apply to the ability of users to add applications do not affect the ability of admins to add applications, and sometimes even admins make mistakes, or apps can get compromised. So, we recommend you regularly audit all of the permissions consented to by admins and users for all applications. You'll need to review both delegated and application permissions. You can look up the applications to which any individual user has granted permissions by using the Azure Active Directory Portal.

1. Sign in to the Azure Portal with administrative rights.
2. Select the “Azure Active Directory” blade.
3. Select “Users.”
4. Select the user that you want to review.
5. Select “Applications.”

This will show you the apps that are assigned to the user, and what permissions the applications have. Here are some things to keep an eye out for:

• "Read" and "Write" permission or "*.All" permission
• ConsentType is “AllPrincipals” - The AllPrincipals permission allows the client application to access everyone's content in the tenancy. In general, only Microsoft 365 applications need this permission.
• High profile or high impact users (e.g. executives, admins, etc) that have inappropriate consents granted
• Suspicious ClientDisplayNames (e.g. DocuSign2, boxx, etc.)
• Suspicious Domain name (e.g. akamacloud.pro, azurecloud.pro)
• Application permissions vs Delegation permissions
• Application: persist even when the user granting no has permission to the target resources or even the granting user no longer exists. (creates a SPN record)
• Delegation: permissions are tied to the grantor; if grantors are revoked, applications permissions are also revoked.

If you see any of these things, follow up with the approver to determine whether these applications are legitimate. If not, immediately remove them.

1. Navigate to the affected user in the Azure Active Directory User blade.
2. Select Applications.
3. Select the illicit application.
4. Click Remove in the drill down.

Conclusion

These configurations will reduce risk, though monitoring for suspicious activity in your O365 account will still be necessary. To see how ActZero helps detect and respond to threats like these, check out our product page.